www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1003 Formal Review

reply Mike Parker <aldacron gmail.com> writes:
The first stage of the formal review for DIP 1003 [1], "Remove 
body as a Keyword", is now underway. From now until 11:59 PM ET 
on May 26 (3:59 AM GMT on May 27), the community has the 
opportunity to provide last-minute feedback. If you missed the 
preliminary review [2], this is your chance to provide input.

At the end of the feedback period, I will submit the DIP to 
Walter and Andrei for their final decision. Thanks in advance to 
those of you who participate.

[1] 
https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

[2] 
http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
May 12
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 12, 2017 at 04:17:03PM +0000, Mike Parker via Digitalmars-d wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as
 a Keyword", is now underway. From now until 11:59 PM ET on May 26
 (3:59 AM GMT on May 27), the community has the opportunity to provide
 last-minute feedback. If you missed the preliminary review [2], this
 is your chance to provide input.
 
 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.
 
 [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
 
 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
I vote for Option 3: make `body` an optional keyword for a release, then deprecate it for another release, then Kill It With Fire. I completely agree with the rationale stated in the DIP, that `body` is a commonly used identifier and therefore should not be a keyword; but even more so that `body` serves little purpose in the language because it is used only in *one* context, and in that context it's not even strictly necessary as no grammar ambiguity would arise from removing it. I disagree that `function` is not overloaded: it *will* be overloaded if option 2 is chosen, because `function` currently means function *pointer*, not the function body itself. For this reason, I oppose Option 2. I also dislike option 1 because contextual keywords represent incongruity in the language, and lately I've come to the conclusion that incongruities will ultimately become inhibitors of progress and sources of problems. (There is more to it than that, but this subject in its generality is OT here so I'll just leave it at that.) Furthermore, as I've said, `body` is not even necessary in the single, only context in which it's used. It does not serve to disambiguate anything, because no grammar ambiguity would result from its absence. So I regard it something completely redundant that the language would do better without. Even though option 3 entails eventual code breakage, I for one would welcome that because it would reduce the amount of unnecessary syntax in my code. A possible compromise could be to make `body` both contextual and optional, so that no existing code will break, but new code also can be freed from the unnecessary syntactic noise and the identifier `body` can be freed up for user use. T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
May 12
parent reply Kagamin <spam here.lot> writes:
On Friday, 12 May 2017 at 18:03:43 UTC, H. S. Teoh wrote:
 I disagree that `function` is not overloaded: it *will* be 
 overloaded if option 2 is chosen, because `function` currently 
 means function *pointer*, not the function body itself.  For 
 this reason, I oppose Option 2.
Function literal includes function body.
May 14
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 14.05.2017 18:36, Kagamin wrote:
 On Friday, 12 May 2017 at 18:03:43 UTC, H. S. Teoh wrote:
 I disagree that `function` is not overloaded: it *will* be overloaded
 if option 2 is chosen, because `function` currently means function
 *pointer*, not the function body itself.  For this reason, I oppose
 Option 2.
Function literal includes function body.
auto add = function int(int a,int b)in{ assert(0<=a && 0 <=b && a<=int.max-b); }body{ return a+b; };
May 14
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 05/12/2017 09:17 AM, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide last-minute
 feedback. If you missed the preliminary review [2], this is your chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md


 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 3. Ali
May 12
prev sibling next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove 
 body as a Keyword", is now underway. From now until 11:59 PM ET 
 on May 26 (3:59 AM GMT on May 27), the community has the 
 opportunity to provide last-minute feedback. If you missed the 
 preliminary review [2], this is your chance to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and Andrei for their final decision. Thanks in advance 
 to those of you who participate.

 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 3. just write //body or /* body */ if you still want to mark the block.
May 12
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/12/17 12:17 PM, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide last-minute
 feedback. If you missed the preliminary review [2], this is your chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md


 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
All seems good to me. I could go with Option 1 or 3. Option 2 seems unnecessary. -Steve
May 12
prev sibling next sibling parent Eugene Wissner <belka caraus.de> writes:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove 
 body as a Keyword", is now underway. From now until 11:59 PM ET 
 on May 26 (3:59 AM GMT on May 27), the community has the 
 opportunity to provide last-minute feedback. If you missed the 
 preliminary review [2], this is your chance to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and Andrei for their final decision. Thanks in advance 
 to those of you who participate.

 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
3
May 12
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove 
 body as a Keyword", is now underway. From now until 11:59 PM ET 
 on May 26 (3:59 AM GMT on May 27), the community has the 
 opportunity to provide last-minute feedback. If you missed the 
 preliminary review [2], this is your chance to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and Andrei for their final decision. Thanks in advance 
 to those of you who participate.

 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
3
May 12
prev sibling next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove 
 body as a Keyword", is now underway. From now until 11:59 PM ET 
 on May 26 (3:59 AM GMT on May 27), the community has the 
 opportunity to provide last-minute feedback. If you missed the 
 preliminary review [2], this is your chance to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and Andrei for their final decision. Thanks in advance 
 to those of you who participate.

 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
I vote for option 4 - a combination of 1 and 3: * Make body a contextual keyword * Allow omitting it * No need for deprecation I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context: // 1: int C; C++; // 2: extern (C++) void foo(); And also let's not forget that 'in' and 'out' are both parameter storage classes and keywords in the context of contracts. This has never been a problem for D and other languages are doing great with this feature: https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/contextual-keywords C# also has a way of using identifiers with the same name as reserved keywords: https://github.com/dotnet/csharplang/blob/master/spec/lexical-structure.md#identifiers (as far as I remember Basile tried to implement this, but ran into some problems, so I'm not sure how doable is such a feature for D, in the presence of mixins). Even if for this particular case contextual keywords are not the best solution (I disagree), I believe that dismissing them would be mistake. They are a powerful technique in language design that allows evolution of the language without the issues with associated with changing the meaning of / breaking existing user code.
May 13
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Saturday, 13 May 2017 at 08:50:10 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove 
 body as a Keyword", is now underway. From now until 11:59 PM 
 ET on May 26 (3:59 AM GMT on May 27), the community has the 
 opportunity to provide last-minute feedback. If you missed the 
 preliminary review [2], this is your chance to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and Andrei for their final decision. Thanks in advance 
 to those of you who participate.

 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
I vote for option 4 - a combination of 1 and 3: * Make body a contextual keyword * Allow omitting it * No need for deprecation I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context: // 1: int C; C++; // 2: extern (C++) void foo(); And also let's not forget that 'in' and 'out' are both parameter storage classes and keywords in the context of contracts. This has never been a problem for D and other languages are doing great with this feature: https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/contextual-keywords C# also has a way of using identifiers with the same name as reserved keywords: https://github.com/dotnet/csharplang/blob/master/spec/lexical-structure.md#identifiers (as far as I remember Basile tried to implement this, but ran into some problems, so I'm not sure how doable is such a feature for D, in the presence of mixins). Even if for this particular case contextual keywords are not the best solution (I disagree), I believe that dismissing them would be mistake. They are a powerful technique in language design that allows evolution of the language without the issues with associated with changing the meaning of / breaking existing user code.
Correction: 'in' and 'out' are not contextual keywords, they are an example of giving keywords different meanings in different contexts, just like 'static'. AFAIK, you can't use them for identifiers, like 'C' - think 'extern (C)'.
May 13
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote:
 On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove
 body as a Keyword", is now underway. From now until 11:59 PM ET
 on May 26 (3:59 AM GMT on May 27), the community has the
 opportunity to provide last-minute feedback. If you missed the
 preliminary review [2], this is your chance to provide input.

 At the end of the feedback period, I will submit the DIP to
 Walter and Andrei for their final decision. Thanks in advance
 to those of you who participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba
 555/DIPs/DIP1003.md

 [2]
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
I vote for option 4 - a combination of 1 and 3: * Make body a contextual keyword * Allow omitting it * No need for deprecation I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context: // 1: int C; C++; // 2: extern (C++) void foo();
Except that C++ is not a keyword anymore than linux is a keyword in version(linux) It's an identifier (albeit one that doesn't quite follow the normal naming scheme for identifiers). D does not have contextual keywords, and Walter is completely against adding them, so I'd expect that any proposal that required them would be DOA. And not having them definitely simplifies lexing and parsing D code, so it's quite understandable that Walter is against them. - Jonathan M Davis
May 13
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Saturday, 13 May 2017 at 10:46:51 UTC, Jonathan M Davis wrote:
 On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote:
 On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], 
 "Remove body as a Keyword", is now underway. From now until 
 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community 
 has the opportunity to provide last-minute feedback. If you 
 missed the preliminary review [2], this is your chance to 
 provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and Andrei for their final decision. Thanks in 
 advance to those of you who participate.

 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba
555/DIPs/DIP1003.md

 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
I vote for option 4 - a combination of 1 and 3: * Make body a contextual keyword * Allow omitting it * No need for deprecation I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context: // 1: int C; C++; // 2: extern (C++) void foo();
Except that C++ is not a keyword anymore than linux is a keyword in version(linux) It's an identifier (albeit one that doesn't quite follow the normal naming scheme for identifiers).
No, they're not the same. 'something' in 'version (something)' or 'debug (something)' can be either: 1) an integer 2) 'assert' or 'unittest' keyword 3) an identifier. 'debug' and 'version' identifiers live in their own namespaces which is why they don't conflict with other identifiers in the program. 'linux' in the context of 'version (linux)' is 3) - a predefined version identifier, and like all other identifiers it has to obey by a certain set of rules [1]. E.g. you can't have 'version (C++-interop)'. Contextual keywords [2] like 'C++', 'Objective-C' or 'exit' on the other hand are not identifiers and that's why don't need to follow [1]. The fact that the spec refuses to call them keywords [3] and they are parsed as identifiers [4],[5] (but only the 'C' and 'Objective' parts) in dmd is an artifact of an implementation detail. In essence, they behave exactly as contextual keywords in C# [6]. But just for fun, let's say I play you're game. Then why not make 'body' an identifier living in it's own namespace, just like 'failure' and 'exit'? :P
 ... and Walter is completely against adding them, so I'd expect 
 that any proposal that required them would be DOA. And not 
 having them definitely simplifies lexing and parsing D code, so 
 it's quite understandable that Walter is against them.
You're just trying to represent Walter's opinion without adding new information. Adding contextual keywords to a language with context free grammar won't make the language grammar context dependent and that's why I don't buy the argument that this would somehow complicate the process parsing D code. Yes, it may require changes to dmd, but in general it's not a difficult problem to solve, as other language implementation demonstrate quite well. [0]: https://dlang.org/spec/version.html#version [1]: https://dlang.org/spec/lex.html#Identifier [2]: See Timon's post for a more complete list: http://forum.dlang.org/post/of6n2e$2ne2$1 digitalmars.com [3]: http://dlang.org/spec/attribute.html#linkage [4]: https://github.com/dlang/dmd/blob/v2.074.0/src/ddmd/parse.d#L2148 [5]: https://github.com/dlang/dmd/blob/v2.074.0/src/ddmd/parse.d#L5418 [6]: https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/contextual-keywords
May 13
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 13 May 2017 at 10:46:51 UTC, Jonathan M Davis wrote:
 be DOA. And not having them definitely simplifies lexing and 
 parsing D code, so it's quite understandable that Walter is 
 against them.
I don't see how it complicates the lexer? "body" would be a valid identifier, so it would be lexed as such. All the parser has to do is to check the content of the identifer-token.
May 14
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12.05.2017 18:17, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide last-minute
 feedback. If you missed the preliminary review [2], this is your chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md


 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 1 is good: There is nothing wrong with the current syntax. [1] Option 2 is bad: It's the function body, not the function. Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement. [1] Also, here is a list of existing contextual keywords: exit success failure C C++ D Windows Pascal System Objective-C
May 13
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 On 12.05.2017 18:17, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove 
 body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 
 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide 
 last-minute
 feedback. If you missed the preliminary review [2], this is 
 your chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and
 Andrei for their final decision. Thanks in advance to those of 
 you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md


 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 1 is good: There is nothing wrong with the current syntax. [1] Option 2 is bad: It's the function body, not the function. Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement.
Hmm, I guess it depends on how you format your code. I noticed that you tend to avoid whitespace when formatting your own code (e.g. [0]) so if '{}{}' was allowed (in addition to '()()') your code would look even more cryptic (at least to me) :P The Phobos style guide, which also mostly matches my personal preference is to write code like this: T sqrt(T)(T n) if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt)) in { assert(n >= 0); } out (result) { assert(result * result == n); } body { //Implementation } If the block is short I sometimes write it like so: T sqrt(T)(T n) if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt)) in { assert(n >= 0); } out (result) { assert(result * result == n); } body { //Implementation } With removal of 'body', the code would look like so: T sqrt(T)(T n) if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt)) in { assert(n >= 0); } out (result) { assert(result * result == n); } { //Implementation } Which I actually think looks good. A small improvement, in addition to omitting 'body' would be to allow omitting the braces if the 'in' or 'out' blocks contain only a single statement (similar to 'if', 'foreach', etc.) and to add a similar syntax sugar alternative for template constraints: T sqrt(T)(T n) if Unqual!T U: isNumeric!U || is(U == BigInt) in n >= 0 out (result) result * result == n { //Implementation } [0]: https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/semantic.d#L845 https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/parser.d#L122 https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/semantic.d#L131
May 13
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 On 12.05.2017 18:17, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide last-minute
 feedback. If you missed the preliminary review [2], this is your chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md



 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 1 is good: There is nothing wrong with the current syntax. [1] Option 2 is bad: It's the function body, not the function. Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement.
Hmm, I guess it depends on how you format your code.
No, it does not. This was a point about the grammar. How would you feel about: if(condition){ then(); } { otherwise(); }
May 13
next sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
 On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 On 12.05.2017 18:17, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], 
 "Remove body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 
 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide 
 last-minute
 feedback. If you missed the preliminary review [2], this is 
 your chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and
 Andrei for their final decision. Thanks in advance to those 
 of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md



 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 1 is good: There is nothing wrong with the current syntax. [1] Option 2 is bad: It's the function body, not the function. Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement.
Hmm, I guess it depends on how you format your code.
No, it does not. This was a point about the grammar. How would you feel about: if(condition){ then(); } { otherwise(); }
It isn't the same. 1) It is ambiguous: { otherwise(); } can be a statement in a block or an else condition. But it wasn't the real point. 2) Nested ifs are used much more often than nested functions, and the code with a lot of nested ifs would look unreadable without else. It isn't the case for the functions. I suppose that contracts a mostly used on outer functions and it would look pretty clear.
May 13
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 13.05.2017 20:26, Eugene Wissner wrote:
 On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
 On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 On 12.05.2017 18:17, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body
 as a
 Keyword", is now underway. From now until 11:59 PM ET on May 26
 (3:59 AM
 GMT on May 27), the community has the opportunity to provide
 last-minute
 feedback. If you missed the preliminary review [2], this is your
 chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md




 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 1 is good: There is nothing wrong with the current syntax. [1] Option 2 is bad: It's the function body, not the function. Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement.
Hmm, I guess it depends on how you format your code.
No, it does not. This was a point about the grammar. How would you feel about: if(condition){ then(); } { otherwise(); }
It isn't the same. ...
It does not need to be "the same", and I didn't claim it was "the same". I'm just trying to illustrate why it does not fit into the D grammar. There is no technical point here. "Ugly" does not mean "unreadable" or "broken". It just means it is bad taste. YMMV.
May 13
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
 On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 On 12.05.2017 18:17, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], 
 "Remove body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 
 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide 
 last-minute
 feedback. If you missed the preliminary review [2], this is 
 your chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to 
 Walter and
 Andrei for their final decision. Thanks in advance to those 
 of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md



 [2] 
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 1 is good: There is nothing wrong with the current syntax. [1] Option 2 is bad: It's the function body, not the function. Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement.
Hmm, I guess it depends on how you format your code.
No, it does not. This was a point about the grammar. How would you feel about: if(condition){ then(); } { otherwise(); }
I don't see any problem, in fact this is valid code even today - both in C++ and D. And my case still stands - if you were to format the code like this: if (condition) { then(); } { otherwise(); } then the intent would be more obvious. At least in C++ using a plain scope { } is common idiom used to explicitly limit the lifetime of RAII objects declared within it.
May 13
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 14.05.2017 00:07, Petar Kirov [ZombineDev] wrote:
 How would you feel about:

 if(condition){ then(); }
 { otherwise(); }
I don't see any problem, ...
The intention is that in this _hypothetical_ (hence "would") grammar (which is somewhat analogous to what is proposed in 3), the second block would bind to the if-statement as the 'else' case, but I see how that is confusing.
 And my case still stands - if you were to format the code like this:
Again, this is not about formatting. Reformat the code as you wish. With your reformatting, it would actually be even less obvious.
May 13
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 14 May 2017 at 01:30:19 UTC, Timon Gehr wrote:
 On 14.05.2017 00:07, Petar Kirov [ZombineDev] wrote:
 How would you feel about:

 if(condition){ then(); }
 { otherwise(); }
I don't see any problem, ...
The intention is that in this _hypothetical_ (hence "would") grammar (which is somewhat analogous to what is proposed in 3), the second block would bind to the if-statement as the 'else' case, but I see how that is confusing.
 And my case still stands - if you were to format the code like 
 this:
Again, this is not about formatting. Reformat the code as you wish. With your reformatting, it would actually be even less obvious.
I now see what you meant, but the two ideas are not equivalent. Making 'else' optional is not possible, because it can change the meaning of existing code, while making 'body' optional would not. Edit: I may be wrong. Here's a case that's on the edge of ambiguity: void main() { void inner(int x) in { } { writeln("WAT"); } } If 'body' was optional, what would be the output of the program? It turns out that the output would be empty, because function bodies are required for functions with 'in' or 'out' contracts, making the block bind to the 'inner' function, instead of 'main'.
May 14
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/14/17 9:53 AM, Petar Kirov [ZombineDev] wrote:

 Edit: I may be wrong. Here's a case that's on the edge of ambiguity:

 void main()
 {
     void inner(int x)
     in { }
     {
         writeln("WAT");
     }
 }

 If 'body' was optional, what would be the output of the program? It
 turns out
 that the output would be empty, because function bodies are required for
 functions
 with 'in' or 'out' contracts, making the block bind to the 'inner'
 function,
 instead of 'main'.
I don't think this is ambiguous or controversial. We are used to a block that follows a function declaration being that function's body without a special keyword. Look at it this way: void inner(int x) // in {} { writeln("Yeah, this is normal"); } If you uncomment the in clause, it's still pretty normal looking. Not that I'm particularly arguing for making body always optional, I'm fine with continuing to require it. But it's also fine to make it optional IMO. -Steve
May 14
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/13/17 6:07 PM, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
 On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 On 12.05.2017 18:17, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body
 as a
 Keyword", is now underway. From now until 11:59 PM ET on May 26
 (3:59 AM
 GMT on May 27), the community has the opportunity to provide
 last-minute
 feedback. If you missed the preliminary review [2], this is your
 chance
 to provide input.

 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.

 [1]
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md




 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
Option 1 is good: There is nothing wrong with the current syntax. [1] Option 2 is bad: It's the function body, not the function. Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement.
Hmm, I guess it depends on how you format your code.
No, it does not. This was a point about the grammar. How would you feel about: if(condition){ then(); } { otherwise(); }
I don't see any problem, in fact this is valid code even today - both in C++ and D. And my case still stands - if you were to format the code like this: if (condition) { then(); } { otherwise(); } then the intent would be more obvious. At least in C++ using a plain scope { } is common idiom used to explicitly limit the lifetime of RAII objects declared within it.
There is a huge difference. if() {} else {} is semantically completely different than if() {} {} Currently, we already allow omitting body when in/out aren't present: void foo() { } is equivalent to void foo() body { } I think really, option 1 is both the easiest and least disruptive. I'm OK with option 3, but it sure seems like an unnecessary breakage. -Steve
May 14
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 14 May 2017 at 13:04:12 UTC, Steven Schveighoffer 
wrote:
 On 5/13/17 6:07 PM, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
 On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
 On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 [...]
Hmm, I guess it depends on how you format your code.
No, it does not. This was a point about the grammar. How would you feel about: if(condition){ then(); } { otherwise(); }
I don't see any problem, in fact this is valid code even today - both in C++ and D. And my case still stands - if you were to format the code like this: if (condition) { then(); } { otherwise(); } then the intent would be more obvious. At least in C++ using a plain scope { } is common idiom used to explicitly limit the lifetime of RAII objects declared within it.
There is a huge difference. if() {} else {} is semantically completely different than if() {} {}
Obviously. I was just referring to the fact 'if (expr) {} {}' is already valid today and I don't think it confuses anyone with 'if (expr) {} else {}', *if code is formatted and/or commented properly*.
 Currently, we already allow omitting body when in/out aren't 
 present:

 void foo()
 {
 }

 is equivalent to

 void foo()
 body
 {
 }

 I think really, option 1 is both the easiest and least 
 disruptive. I'm OK with option 3, but it sure seems like an 
 unnecessary breakage.

 -Steve
By making body optional and a contextual keyword there should be no breaking changes (except for obscure code like `static assert (!__traits(compiles, { mixin ("int body;"); }))` :D).
May 14
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/14/17 9:24 AM, Petar Kirov [ZombineDev] wrote:
 By making body optional and a contextual keyword there should be no
 breaking changes (except for obscure code like `static assert
 (!__traits(compiles, { mixin ("int body;"); }))` :D).
It doesn't even need to be optional. It can be required as it is now (when in/out are specified), just not a keyword. I believe that this is what is specified in Option 1 of the DIP. -Steve
May 14
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 14 May 2017 at 13:55:44 UTC, Steven Schveighoffer 
wrote:
 On 5/14/17 9:24 AM, Petar Kirov [ZombineDev] wrote:
 By making body optional and a contextual keyword there should 
 be no
 breaking changes (except for obscure code like `static assert
 (!__traits(compiles, { mixin ("int body;"); }))` :D).
It doesn't even need to be optional. It can be required as it is now (when in/out are specified), just not a keyword. I believe that this is what is specified in Option 1 of the DIP. -Steve
Yeah, I'm OK with Option 1. I would just prefer not typing 'body' when writing functions with contracts.
May 14
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
 [1] Also, here is a list of existing contextual keywords:

 exit
 success
 failure
 C
 C++
 D
 Windows
 Pascal
 System
 Objective-C
They are not used alone. They are used in a **statement** and surrounded by parens. It's important because statements start with keywords, which, in a way, makes the contextual keyword less important. "body" as contextual keyword would be only comparable if 1/ "in" and "out" would also be contextual keywords. For example "exit", "success" and "failure" are **all** contextual keywords. 2/ used in a statement, for example "contract": void foo() contract(in){}contract(out){} contract(body){} (i don't say that this is the way to follow, it's more theoretical)
May 14
prev sibling next sibling parent rjframe <dlang ryanjframe.com> writes:
On Fri, 12 May 2017 16:17:03 +0000, Mike Parker wrote:

 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
 GMT on May 27), the community has the opportunity to provide last-minute
 feedback. If you missed the preliminary review [2], this is your chance
 to provide input.
 
 At the end of the feedback period, I will submit the DIP to Walter and
 Andrei for their final decision. Thanks in advance to those of you who
 participate.
 
 [1]
 https://github.com/dlang/DIPs/blob/
fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
 
 [2]
 http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
For option one, there would also need to be a discussion of whether to allow us to use in and out as identifiers for consistency (I used them more often than body in my pre-D programming); I would say no, but could argue either way. It's a slippery slope. I think option three is ugly, but I could live with it. I thought ()() was ugly for templates too, but now they're just normal. How about: void func() in { assert(true); } out { assert(true); } nowWeFinallyGetToTheFunctionBodyProvidedThereWereNoProblems { // I don't think we'll have to worry about name clashes... }
May 13
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2017 9:17 AM, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway.
I'd like to congratulate Jared Hanson for a particularly well-written DIP which sets a high standard for how things ought to be done. Well done!
May 13
parent Meta <jared771 gmail.com> writes:
On Saturday, 13 May 2017 at 13:16:40 UTC, Walter Bright wrote:
 On 5/12/2017 9:17 AM, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove 
 body as a
 Keyword", is now underway.
I'd like to congratulate Jared Hanson for a particularly well-written DIP which sets a high standard for how things ought to be done. Well done!
Thank you. Actually, I'd like to ask, are you still as strongly in opposition to making `body` a contextual keyword as you were previously? To me that seems to be the easiest solution, although I am happy going with any of the three proposed solutions.
May 13
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2017 9:17 AM, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway.
A combination of Options 1 and 2: 1. Introduce 'function' as an alternative to 'body'. 2. Turn 'body' into a contextual keyword. 3. Deprecate 'body' as a contextual keyword. 4. Eventually remove 'body' as a contextual keyword. The advantages of this are: 1. 'body' can immediately be used as a regular identifier. 2. Existing code is not immediately broken. 3. Can have a decent deprecation period for users using 'body'. 4. No long term problems with contextual keywords.
May 14
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 14.05.2017 17:39, Walter Bright wrote:
 On 5/12/2017 9:17 AM, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway.
A combination of Options 1 and 2: 1. Introduce 'function' as an alternative to 'body'. 2. Turn 'body' into a contextual keyword. 3. Deprecate 'body' as a contextual keyword. 4. Eventually remove 'body' as a contextual keyword. The advantages of this are: 1. 'body' can immediately be used as a regular identifier. 2. Existing code is not immediately broken. 3. Can have a decent deprecation period for users using 'body'. 4. No long term problems with contextual keywords.
The drawback is that option 2 is not a good option.
May 14
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, May 14, 2017 08:39:12 Walter Bright via Digitalmars-d wrote:
 On 5/12/2017 9:17 AM, Mike Parker wrote:
 The first stage of the formal review for DIP 1003 [1], "Remove body as a
 Keyword", is now underway.
A combination of Options 1 and 2: 1. Introduce 'function' as an alternative to 'body'. 2. Turn 'body' into a contextual keyword. 3. Deprecate 'body' as a contextual keyword. 4. Eventually remove 'body' as a contextual keyword. The advantages of this are: 1. 'body' can immediately be used as a regular identifier. 2. Existing code is not immediately broken. 3. Can have a decent deprecation period for users using 'body'. 4. No long term problems with contextual keywords.
Why would we want to introduce function as an alternative to body? Personally, I've always found the need to use body to be very odd and annoying. It doesn't need to be there when you don't have in or out contracts, and it just makes contracts that much more verbose. It's not even like you can put in our out contracts after the function body, so body is needed to indicate which block the function body is - the contracts have to go first. So, as far as I can tell, body serves no useful function. It just makes the code longer, and the amount of extra code required around in/out contracts is part of why I almost never use them. In most cases, it just makes more sense to put the assertions in the function body and not have all of that extra plumbing right after the function signature. So, while I do like the idea of getting the word body back as an identifier, what really appeals to me here is getting rid of the need for it with contracts. And using function instead of body doesn't help that at all. If we need a keyword there, then I agree that function is a good fit, but I don't understand why having a keyword there is even beneficial. As far as I can tell, it doesn't solve any ambiguity; it's inconsistent with function declarations that don't have contracts; and it's just making an already annoyingly verbose construct that much more verbose. I like the idea of doing the deprecation in a way that avoids having contextual keywords in the long run, and having the ability to use body as identifier immediately would be nice - so in that sense, your proposal seems good - but I'd _really_ like to see it be the case ultimately that no keyword is needed for function bodies even when in/out contracts are used. - Jonathan M Davis
May 14
parent reply MysticZach <reachzach ggmail.com> writes:
On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
 Why would we want to introduce function as an alternative to 
 body? Personally, I've always found the need to use body to be 
 very odd and annoying. It doesn't need to be there when you 
 don't have in or out contracts, and it just makes contracts 
 that much more verbose. It's not even like you can put in our 
 out contracts after the function body, so body is needed to 
 indicate which block the function body is - the contracts have 
 to go first. So, as far as I can tell, body serves no useful 
 function. It just makes the code longer, and the amount of 
 extra code required around in/out contracts is part of why I 
 almost never use them. In most cases, it just makes more sense 
 to put the assertions in the function body and not have all of 
 that extra plumbing right after the function signature.
Not that a whole new way of doing things is called for... but I think a better design would have been to allow 'in' and 'out' statements in the function itself, with no need for brackets if you only have one line's worth of contract, e.g., int fun(int a) { in assert(...); out(x) assert(...); // do stuff }
May 14
next sibling parent MysticZach <reachzach ggmail.com> writes:
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
 Not that a whole new way of doing things is called for... but I 
 think a better design would have been to allow 'in' and 'out' 
 statements in the function itself, with no need for brackets if 
 you only have one line's worth of contract, e.g.,

 int fun(int a) {
   in assert(...);
   out(x) assert(...);

   // do stuff
 }
You could even accumulate in statement if you want to save on brackets and indentation: int fun() { in assert(...); in assert2(...); // etc. }
May 14
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
 Not that a whole new way of doing things is called for... but I 
 think a better design would have been to allow 'in' and 'out' 
 statements in the function itself, with no need for brackets if 
 you only have one line's worth of contract, e.g.,

 int fun(int a) {
   in assert(...);
   out(x) assert(...);

   // do stuff
 }
It's nice, i like it but it cant work as simply. You're forgetting that interface member functions can have contracts. With this syntax interfaces member functions would always have a body BUT the current semantic is that interface member functions with bodies are final methods. Boom. Interfaces don't work anymore because there's no easy way to make the difference between an interface member function that's final and an interface member function that's not pre-implemented (so overridable) but has contracts.
May 14
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
Currently function declarations with contracts don't require semicolon at the end. This conflicts with options 1 and 3 and is not addressed in the DIP.
May 14
parent Meta <jared771 gmail.com> writes:
On Sunday, 14 May 2017 at 16:35:32 UTC, Kagamin wrote:
 On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 [1] 
 https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
Currently function declarations with contracts don't require semicolon at the end. This conflicts with options 1 and 3 and is not addressed in the DIP.
I'm confused as to how this conflicts with option 1. Can you explain?
May 14
prev sibling parent Adrian Matoga <dlang.spam matoga.info> writes:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
 ...
3. deprecate, remove, forget. During the deprecation period, it could live as "contextual keyword", or actually with grammar modified to expect an identifier "body" instead of keyword. That would allow using "body" as identifier immediately.
May 15