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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 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 2017
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 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 2017
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 2017
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 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
prev sibling next 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 2017
next sibling 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 2017
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 2017
prev sibling parent reply 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 2017
next sibling parent reply MysticZach <reachzach ggmail.com> writes:
On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
 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.
It seems to me that the compiler could detect a presence or lack of a body simply by the presence or absence of any statement after the contracts, i.e., interface D { // fun is implicitly overridable here int fun() { in assert(...); } } Also, does a final function with contracts, but no body, make any sense? What's the use case? Even if there were some use case for it, I can think of two solutions. One is to keep and require the current syntax for an interface function without a body. This is the natural way to install contracts anyway, for a function with no body. The other solution is to recommend the addition of an empty statement, for an empty final function, e.g.: // final int fun() { in assert(...); {} } Considering what Jonathan said about how he never uses contracts because they're so bulky, might it not be worth it to solve the interface problem in either of the above two ways?
May 15 2017
next sibling parent MysticZach <reachzach ggmail.com> writes:
On Tuesday, 16 May 2017 at 03:44:54 UTC, MysticZach wrote:
 It seems to me that the compiler could detect a presence or 
 lack of a body simply by the presence or absence of any 
 statement after the contracts, i.e.,

 interface D {
   // fun is implicitly overridable here
   int fun() {
     in assert(...);
   }
 }

 Also, does a final function with contracts, but no body, make 
 any sense? What's the use case?

 Even if there were some use case for it, I can think of two 
 solutions. One is to keep and require the current syntax for an 
 interface function without a body. This is the natural way to 
 install contracts anyway, for a function with no body.

 The other solution is to recommend the addition of an empty 
 statement, for an empty final function, e.g.:

 // final
 int fun() {
   in assert(...);
   {}
 }

 Considering what Jonathan said about how he never uses 
 contracts because they're so bulky, might it not be worth it to 
 solve the interface problem in either of the above two ways?
I should have said *three* ways, because it's quite possible to conclude that there will never be a use case for a final function in an interface to have contracts, but no body, and therefore assume that contracts plus a lack of statements --> an overridable function.
May 15 2017
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 16.05.2017 05:44, MysticZach wrote:
 ...
With your proposal, this syntax would already be taken for a function with an empty implementation.
 Also, does a final function with contracts, but no body, make any sense?
 What's the use case?
 ...
di files.
 Even if there were some use case for it, I can think of two solutions.
 One is to keep and require the current syntax for an interface function
 without a body. This is the natural way to install contracts anyway, for
 a function with no body.

 The other solution is to recommend the addition of an empty statement,
 for an empty final function, e.g.:

 // final
 int fun() {
   in assert(...);
   {}
 }

 Considering what Jonathan said about how he never uses contracts because
 they're so bulky, might it not be worth it to solve the interface
 problem in either of the above two ways?
No. Contracts are not part of the function body, they are part of the function signature. That's the point.
May 15 2017
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
 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.
I agree with your points, but it doesn't necessarily preclude adding in/out statements. My only qualm is that they would seem very similar to scope statements. Perhaps scope(in) and scope(out(x)) or something like that. Would not break any code to do it.
May 16 2017
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 16 May 2017 at 21:39:19 UTC, jmh530 wrote:
 I agree with your points, but it doesn't necessarily preclude 
 adding in/out statements. My only qualm is that they would seem 
 very similar to scope statements. Perhaps scope(in) and 
 scope(out(x)) or something like that. Would not break any code 
 to do it.
I meant adding in/out statements without removing the in/out block functionality the way it is now.
May 16 2017
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
 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.
The purpose of the DIP is to reclaim the keyword. If you want shorter contracts, then: int f(int a) in assert(a>0) out(r) assert(b==a+1) { return a+1; }
May 16 2017
parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 16 May 2017 at 10:28:09 UTC, Kagamin wrote:
 On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
 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.
The purpose of the DIP is to reclaim the keyword. If you want shorter contracts, then: int f(int a) in assert(a>0) out(r) assert(b==a+1) { return a+1; }
Yes, please keep the discussion focused on the the removal of `body` and how to best go about that. I do agree though that we could and should make contracts shorter. Maybe in another DIP after this one.
May 16 2017
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, May 16, 2017 12:50:37 Meta via Digitalmars-d wrote:
 On Tuesday, 16 May 2017 at 10:28:09 UTC, Kagamin wrote:
 On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
 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.
The purpose of the DIP is to reclaim the keyword. If you want shorter contracts, then: int f(int a) in assert(a>0) out(r) assert(b==a+1) { return a+1; }
Yes, please keep the discussion focused on the the removal of `body` and how to best go about that. I do agree though that we could and should make contracts shorter. Maybe in another DIP after this one.
All I'm arguing for is that if we're removing body as a keyword, there's no need to replace it with function or any other word in contracts. We can simply deprecate its use as a keyword and not replace it, letting it then be used as a normal identifier in whatever fashion makes the most sense. Actually changing the overall syntax of contracts is a whole other can of worms. - Jonathan M Davis
May 16 2017
parent MysticZach <reachzach ggmail.com> writes:
On Tuesday, 16 May 2017 at 13:50:59 UTC, Jonathan M Davis wrote:
 All I'm arguing for is that if we're removing body as a 
 keyword, there's no need to replace it with function or any 
 other word in contracts. We can simply deprecate its use as a 
 keyword and not replace it, letting it then be used as a normal 
 identifier in whatever fashion makes the most sense.
+1, Makes total sense to me. So simple. I'm for this.
 Actually changing the overall syntax of contracts is a whole 
 other can of worms.
Yeah. One thing at a time.
May 16 2017
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:
 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.
auto foo()in{ assert(true); }out{ assert(true); }{ return 3; } Are you really arguing for this? I don't want to write code like this.
May 16 2017
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, May 16, 2017 17:22:12 Timon Gehr via Digitalmars-d wrote:
 On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:
 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.
auto foo()in{ assert(true); }out{ assert(true); }{ return 3; } Are you really arguing for this? I don't want to write code like this.
Well, I can't say that I like the formatting, but most definietly I am arguing for that. Right now, just because you add contracts, you suddenly have to add an extra keyword that is unnecessary when there are no contracts and which is redundant. You go from having something like auto foo(T param) { ... } to something like auto foo(T param) in { assert(...); } out(result) { assert(...); } body { ... } or auto foo(T param) in { assert(...); } out(result) { assert(...); } body { ... } or however you want to format it. But the last set of braces is always the function body just like it is when there are no contracts. And having to have body (or function whatever other keyword we might put there) just makes contracts that much more verbose - as well as being inconsistent with how functions bodies are declared when there are no contracts. Honestly, as nice as it would be to get the body keyword back as an identifier, I care _way_ more about not having a redundant keyword for the function body. I'd be all for removing it from contracts even if we never got it back as an identifier. I've always found needing to add body to be very annoying, and I frequently forget it, because it's not there normally. It's just making contracts longer without adding extra information, and contracts are _way_ too verbose even without the extra keyword there, let alone with it. IMHO, if we remove body as a keyword but replace it with something else in contracts, we've lost out on a big opportunity for some language cleanup. - Jonathan M Davis
May 16 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 16.05.2017 17:47, Jonathan M Davis via Digitalmars-d wrote:
 ...

 And having to
 have body (or function whatever other keyword we might put there) just makes
 contracts that much more verbose
That's seriously exaggerated.
 - as well as being inconsistent with how
 functions bodies are declared when there are no contracts.

 Honestly, as nice as it would be to get the body keyword back as an
 identifier, I care _way_ more about not having a redundant keyword for the
 function body.
It's not redundant. Removing it makes the code look bad. There is a reason why Walter added it to the language.
 I'd be all for removing it from contracts even if we never
 got it back as an identifier. I've always found needing to add body to be
 very annoying, and I frequently forget it,
Impossible. You "almost never use" contracts.
 because it's not there normally.
It's always there if you write a function with contracts.
 It's just making contracts longer without adding extra information, and
 contracts are _way_ too verbose even without the extra keyword there, let
 alone with it.
I'm not against adding less verbose options, but just removing 'body' is not a good way to do it. All that does is to go from verbose to verbose and ugly. That does not justify a change that breaks all D code that uses contracts.
 IMHO, if we remove body as a keyword but replace it with something else in
 contracts, we've lost out on a big opportunity for some language cleanup.

 - Jonathan M Davis
I disagree that changing contract syntax in the way you suggest constitutes a cleanup. I agree that changing 'body' to 'function' is a similarly bad option though.
May 16 2017
prev sibling parent reply MysticZach <reachzach ggmail.com> writes:
On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
 auto foo()in{
     assert(true);
 }out{
     assert(true);
 }{
     return 3;
 }

 Are you really arguing for this?
 I don't want to write code like this.
It's not any better than this: auto foo()in{ assert(true); }out{ assert(true); }body{ return 3; } They are both bad, but not because of the presence or absence of the `body` keyword, in my opinion.
May 16 2017
parent reply MysticZach <reachzach ggmail.com> writes:
On Tuesday, 16 May 2017 at 17:42:11 UTC, MysticZach wrote:
 On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
 auto foo()in{
     assert(true);
 }out{
     assert(true);
 }{
     return 3;
 }

 Are you really arguing for this?
 I don't want to write code like this.
It's not any better than this:
I meant any worse.
May 16 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 16.05.2017 19:44, MysticZach wrote:
 On Tuesday, 16 May 2017 at 17:42:11 UTC, MysticZach wrote:
 On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
 auto foo()in{
     assert(true);
 }out{
     assert(true);
 }{
     return 3;
 }

 Are you really arguing for this?
 I don't want to write code like this.
It's not any better than this:
I meant any worse.
Yes, it is actually worse.
May 16 2017
prev sibling parent reply Random D user <no email.com> writes:
On Sunday, 14 May 2017 at 15:39:12 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.
A combination of Options 1 and 2: 1. Introduce 'function' as an alternative to 'body'.
How about using some other keyword like, with, else, scope or do, for example. Would they read better than 'function' (i.e. function with vs. function function vs. function body)? Let's experiment a bit. int foo() in { } out { } with { bar(); } -- or int foo() in { } out { } else // I guess this could be too confusing with template constraint? See below. { bar(); } int foo(T)() if(cond) in { } out { } else { } -- or int foo() in { } out { } scope { bar(); } -- or int foo() in { } out { } do { bar(); }
May 16 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/16/2017 01:59 PM, Random D user wrote:
 int foo()
 in
 {
 }
 out
 {
 }
 do
 {
   bar();
 }
Can't deny I like that. -- Andrei
May 16 2017
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 16.05.2017 20:06, Andrei Alexandrescu wrote:
 On 05/16/2017 01:59 PM, Random D user wrote:
 int foo()
 in
 {
 }
 out
 {
 }
 do
 {
   bar();
 }
Can't deny I like that. -- Andrei
Beats options 2 and 3.
May 16 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, May 16, 2017 at 08:43:01PM +0200, Timon Gehr via Digitalmars-d wrote:
 On 16.05.2017 20:06, Andrei Alexandrescu wrote:
 On 05/16/2017 01:59 PM, Random D user wrote:
 
 int foo()
 in
 {
 }
 out
 {
 }
 do
 {
   bar();
 }
Can't deny I like that. -- Andrei
Beats options 2 and 3.
To me, it's actually worse, because now you have a visual conflation with do-loops. Overall, what I don't like about contract syntax is that it is so unbearably verbose. It's not just the in and out blocks and the (IMO redundant) marking of the function body; it's also the repeated 'assert's that occur in the in and out blocks. int foo(T, U)(T t, U u) if (sigContraints!T && sigConstraints!U) in { assert(t > 0 && u < 10); } out(val) { assert(val > 1 && val < 5); } body { // function body here } I understand this DIP is only to address the `body` part of this ugly verbosity, but imagine how much better it would be if we could write something like this instead: int foo(T, U)(T t, U u) if (sigConstraints!T && sigConstraints!U) in (t > 0 && u < 10) out(foo > 1 && foo < 5 ) { // function body here } This is just tentative example syntax, of course. We can argue over its fine points later, but the point is that the current syntax is far too verbose, and can easily be reduced to half the number of lines. Merely changing `body` to `do` does nothing to address this, and seems to me to be just more useless churn, replacing one bit of verbosity with another bit of verbosity. (Not to mention the IMO very ugly syntax clash with do-loops, which will reduce code readability even more.) T -- I think the conspiracy theorists are out to get us...
May 16 2017
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
 this ugly verbosity, but imagine how much better it would be if 
 we could write something like this instead:

 	int foo(T, U)(T t, U u)
 	if (sigConstraints!T && sigConstraints!U)
 	in (t > 0 && u < 10)
 	out(foo > 1 && foo < 5 )
 	{
 		// function body here
 	}

 This is just tentative example syntax, of course.
Why not just use the terminology the rest of the world has landed on? int foo(T, U)(T t, U u) if (sigConstraints!T && sigConstraints!U) requires(t > 0 && u < 10) ensures(foo > 1 && foo < 5 ) { // function body here } Or is there some value in being cryptic?
May 16 2017
parent reply Eugene Wissner <belka caraus.de> writes:
On Tuesday, 16 May 2017 at 19:18:43 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
 this ugly verbosity, but imagine how much better it would be 
 if we could write something like this instead:

 	int foo(T, U)(T t, U u)
 	if (sigConstraints!T && sigConstraints!U)
 	in (t > 0 && u < 10)
 	out(foo > 1 && foo < 5 )
 	{
 		// function body here
 	}

 This is just tentative example syntax, of course.
Why not just use the terminology the rest of the world has landed on? int foo(T, U)(T t, U u) if (sigConstraints!T && sigConstraints!U) requires(t > 0 && u < 10) ensures(foo > 1 && foo < 5 ) { // function body here } Or is there some value in being cryptic?
What about error messages. With asserts I get the line where the assert failed. Can I get an information which condition failed (sorry for the question, I don't know how it works in other languages)?
May 16 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 16 May 2017 at 19:23:28 UTC, Eugene Wissner wrote:
 What about error messages. With asserts I get the line where 
 the assert failed. Can I get an information which condition 
 failed (sorry for the question, I don't know how it works in 
 other languages)?
Use multiple requires/ensures clauses?
May 16 2017
parent Eugene Wissner <belka caraus.de> writes:
On Tuesday, 16 May 2017 at 19:24:43 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 16 May 2017 at 19:23:28 UTC, Eugene Wissner wrote:
 What about error messages. With asserts I get the line where 
 the assert failed. Can I get an information which condition 
 failed (sorry for the question, I don't know how it works in 
 other languages)?
Use multiple requires/ensures clauses?
That makes sense.
May 16 2017
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 16.05.2017 20:57, H. S. Teoh via Digitalmars-d wrote:
 On Tue, May 16, 2017 at 08:43:01PM +0200, Timon Gehr via Digitalmars-d wrote:
 On 16.05.2017 20:06, Andrei Alexandrescu wrote:
 On 05/16/2017 01:59 PM, Random D user wrote:
 int foo()
 in
 {
 }
 out
 {
 }
 do
 {
   bar();
 }
Can't deny I like that. -- Andrei
Beats options 2 and 3.
To me, it's actually worse, because now you have a visual conflation with do-loops.
It's worse than option 1, but not worse than options 2 and 3. I prefer a visual conflation with do loops over a visual conflation with any of the constructs having 'function' in it, and I'm saying no to this: ... { }{ }
 Overall, what I don't like about contract syntax is that it is so
 unbearably verbose.
It's quite verbose, but certainly not unbearably so.
 It's not just the in and out blocks and the (IMO
 redundant)  marking of the function body;
There are many redundant elements in the D grammar. It's not a bad thing per se.
 it's also the repeated
 'assert's that occur in the in and out blocks.

 	int foo(T, U)(T t, U u)
 	if (sigContraints!T && sigConstraints!U)
 	in
 	{
 		assert(t > 0 && u < 10);
 	}
 	out(val)
 	{
 		assert(val > 1 && val < 5);
 	}
 	body
 	{
 		// function body here
 	}

 I understand this DIP is only to address the `body` part of this ugly
 verbosity,
Actually, the goal of the DIP is to make 'body' not a keyword. Nothing more.
 but imagine how much better it would be if we could write
 something like this instead:

 	int foo(T, U)(T t, U u)
 	if (sigConstraints!T && sigConstraints!U)
 	in (t > 0 && u < 10)
 	out(foo > 1 && foo < 5 )
 	{
 		// function body here
 	}

 This is just tentative example syntax, of course.  We can argue over its
 fine points later, but the point is that the current syntax is far too
 verbose, and can easily be reduced to half the number of lines.  Merely
 changing `body` to `do` does nothing to address this, and seems to me to
 be just more useless churn, replacing one bit of verbosity with another
 bit of verbosity.
It's a good option to have, but D is not an expression-based language, so this can be painful, as you cannot declare intermediate variables nor use statements.
 (Not to mention the IMO very ugly syntax clash with
 do-loops, which will reduce code readability even more.)
...
Do you think your new syntax is significantly more readable? (Just curious.)
May 16 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
 I'm saying no to this:
 
 ...
 {
 
 }{
 
 }
It doesn't have to be formatted that way. For example: int foo() in { assert(blah); } { // not so bad after all } [...]
 	int foo(T, U)(T t, U u)
 	if (sigConstraints!T && sigConstraints!U)
 	in (t > 0 && u < 10)
 	out(foo > 1 && foo < 5 )
 	{
 		// function body here
 	}
 
 This is just tentative example syntax, of course.  We can argue over
 its fine points later, but the point is that the current syntax is
 far too verbose, and can easily be reduced to half the number of
 lines.  Merely changing `body` to `do` does nothing to address this,
 and seems to me to be just more useless churn, replacing one bit of
 verbosity with another bit of verbosity.
It's a good option to have, but D is not an expression-based language, so this can be painful, as you cannot declare intermediate variables nor use statements.
Yes, I'm aware that one of the reasons for the current syntax was the desire to allow arbitrary code inside contracts. In practice, though, I hardly ever encounter a use case that needed this, and even where it was needed, the code was much better off being in a separate function so that you could write, for example: bool elementsWithinRange(T)(T[] data, T lower, T upper) { foreach (e; data) { if (e < lower || e >= upper) return false; } return true; } int foo(T)(T[] data) in { assert(data.elementsWithinRange(0, 10); } body // ugh { ... } In the hypothetical new syntax, you could get rid of the assert altogether for a much more concise expression of the in-contract. IMO, if your contracts have become complex enough to require variables and statements, then it's time to refactor them into properly-named functions so that the person reading the code doesn't have to mentally parse and execute the contract just to understand what requirements it's trying to express. D not being an expression-based language is not a problem since contracts can call arbitrary functions. (In fact, I'd argue it's an advantage, since it would require users to refactor their contracts once it starts getting out-of-hand. The result should be better readability.)
 (Not to mention the IMO very ugly syntax clash with
 do-loops, which will reduce code readability even more.)
 ...
Do you think your new syntax is significantly more readable? (Just curious.)
It at least gets rid of the verbosity of the current syntax. I don't claim it's necessarily *significantly* more readable, but I'd consider it to be one step closer. Getting all the way there would be another topic, and a very long, protracted one, given our track record. T -- "No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev
May 16 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 16.05.2017 22:00, H. S. Teoh via Digitalmars-d wrote:
 On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
 [...]
 I'm saying no to this:

 ...
 {

 }{

 }
It doesn't have to be formatted that way. For example: int foo() in { assert(blah); } { // not so bad after all }
IMO, this is just as bad. It's the same thing.
 (Not to mention the IMO very ugly syntax clash with
 do-loops, which will reduce code readability even more.)
 ...
Do you think your new syntax is significantly more readable? (Just curious.)
It at least gets rid of the verbosity of the current syntax. I don't claim it's necessarily *significantly* more readable, but I'd consider it to be one step closer. Getting all the way there would be another topic, and a very long, protracted one, given our track record.
But still: If we are going to break all usages of contracts, then why not just fix the entire syntax at once? It just seems to be a much better option than making it worse.
May 16 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2017 12:48 PM, Timon Gehr wrote:
 It's a good option to have, but D is not an expression-based language, so this
 can be painful, as you cannot declare intermediate variables nor use
statements.
You can by using lambdas, but embedded lambdas are rather awkward.
May 17 2017
prev sibling parent reply MysticZach <reachzach ggmail.com> writes:
On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
 To me, it's actually worse, because now you have a visual 
 conflation with do-loops.

 Overall, what I don't like about contract syntax is that it is 
 so unbearably verbose. It's not just the in and out blocks and 
 the (IMO redundant) marking of the function body; it's also the 
 repeated 'assert's that occur in the in and out blocks.

 	int foo(T, U)(T t, U u)
 	if (sigContraints!T && sigConstraints!U)
 	in
 	{
 		assert(t > 0 && u < 10);
 	}
 	out(val)
 	{
 		assert(val > 1 && val < 5);
 	}
 	body
 	{
 		// function body here
 	}

 I understand this DIP is only to address the `body` part of 
 this ugly verbosity, but imagine how much better it would be if 
 we could write something like this instead:

 	int foo(T, U)(T t, U u)
 	if (sigConstraints!T && sigConstraints!U)
 	in (t > 0 && u < 10)
 	out(foo > 1 && foo < 5 )
 	{
 		// function body here
 	}

 This is just tentative example syntax, of course.  We can argue 
 over its fine points later, but the point is that the current 
 syntax is far too verbose, and can easily be reduced to half 
 the number of lines.  Merely changing `body` to `do` does 
 nothing to address this, and seems to me to be just more 
 useless churn, replacing one bit of verbosity with another bit 
 of verbosity. (Not to mention the IMO very ugly syntax clash 
 with do-loops, which will reduce code readability even more.)


 T
I think there are several issues at hand, and they need to be dealt with individually: 1. `body` is a very useful identifier. It would be nice to have it available. 2. Contract syntax is too verbose. 3. a. Some people think code looks better with a keyword, e.g. `body`, `do`, etc. distinguishing the function from the contracts. 3. b. Other people think that such a keyword is unnecessarily redundant and does not justify its own existence. I think the thread will be more productive if the posters commit to answering just one of these issues, and reserve other issues for other threads. As the DIP in question is directly meant to only that problem here.
May 16 2017
next sibling parent Meta <jared771 gmail.com> writes:
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
 I think the thread will be more productive if the posters 
 commit to answering just one of these issues
Agreed. Let's hope it's the topic that the DIP is actually addressing ;-)
May 16 2017
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, May 17, 2017 01:01:29 MysticZach via Digitalmars-d wrote:
 I think there are several issues at hand, and they need to be
 dealt with individually:

 1. `body` is a very useful identifier. It would be nice to have
 it available.

 2. Contract syntax is too verbose.

 3. a. Some people think code looks better with a keyword, e.g.
 `body`, `do`, etc. distinguishing the function from the contracts.

 3. b. Other people think that such a keyword is unnecessarily
 redundant and does not justify its own existence.

 I think the thread will be more productive if the posters commit
 to answering just one of these issues, and reserve other issues
 for other threads. As the DIP in question is directly meant to

 only that problem here.
The issues are not completely separate, because one of the suggestions of how to make the change with regards to body is to replace it with function. So, while we don't need to decide to completely overhaul the syntax for contracts, we do need to decide what we're going to do with the place where body is used now - be it remove the need for body entirely, make it a contextual keyword so that it's still used in contracts but is also usable as an identifier, or replace it with another keyword such as function or do. - Jonathan M Davis
May 16 2017
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:

 I think there are several issues at hand, and they need to be 
 dealt with individually:

 1. `body` is a very useful identifier. It would be nice to have 
 it available.

 2. Contract syntax is too verbose.

 3. a. Some people think code looks better with a keyword, e.g. 
 `body`, `do`, etc. distinguishing the function from the 
 contracts.

 3. b. Other people think that such a keyword is unnecessarily 
 redundant and does not justify its own existence.

 I think the thread will be more productive if the posters 
 commit to answering just one of these issues, and reserve other 
 issues for other threads. As the DIP in question is directly 

 problem and only that problem here.
Let me interject here that the primary issue we should be focused on in this thread is whether or not the status of `body` as a reserved keyword can be revoked and, if so, how to best go about it. Debates about the verbosity of contracts are peripherally related (courtesy of Option 3 in the DIP), but should not be the primary focus of the discussion here. I would also like to remind everyone that the preliminary review of this DIP happened some time ago, and that's the place where free-for-all discussions are appropriate. The purpose of this thread is not to improve or modify the DIP, but to provide Walter and Andrei more food for thought when they consider if and how to implement the DIP. With that in mind, I ask that we try to reduce the noise a bit by focusing on the key points of the DIP. As I see it, these are: * Is it a good idea to remove body's status as a reserved keyword? * If so, which option is best? 1) Make it contextual 2) Replace it with another keyword (`function` was suggested in the DIP, `do` in this thread). 3) A three-stage process of removal: make it optional, then deprecate it, then remove it completely (meaning, no keyword, reserved or contextual, is required for the function body in a contract). If you'd like to discuss peripheral issues in depth, I ask that you start another thread to do so. Feel free to post a link to the new thread in this one. Thanks!
May 17 2017
parent reply MysticZach <reachzach ggmail.com> writes:
On Wednesday, 17 May 2017 at 08:03:13 UTC, Mike Parker wrote:
 * Is it a good idea to remove body's status as a reserved 
 keyword?

 * If so, which option is best?
   1) Make it contextual
   2) Replace it with another keyword (`function` was suggested 
 in the DIP, `do` in this thread).
   3) A three-stage process of removal: make it optional, then 
 deprecate it, then remove it completely (meaning, no keyword, 
 reserved or contextual, is required for the function body in a 
 contract).
Option 4) Keep `body`, but make it both contextual *and* optional. It becomes usable as an identifier, and those who think it's unnecessary are appeased. The downside is that different programmers will include it or not, based on arbitrary preferences.
May 17 2017
parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 17 May 2017 at 09:53:49 UTC, MysticZach wrote:
 On Wednesday, 17 May 2017 at 08:03:13 UTC, Mike Parker wrote:
 * Is it a good idea to remove body's status as a reserved 
 keyword?

 * If so, which option is best?
   1) Make it contextual
   2) Replace it with another keyword (`function` was suggested 
 in the DIP, `do` in this thread).
   3) A three-stage process of removal: make it optional, then 
 deprecate it, then remove it completely (meaning, no keyword, 
 reserved or contextual, is required for the function body in a 
 contract).
Option 4) Keep `body`, but make it both contextual *and* optional. It becomes usable as an identifier, and those who think it's unnecessary are appeased. The downside is that different programmers will include it or not, based on arbitrary preferences.
The problem with this option is the IDEs. D syntax so far doesn't require parsing to highlight, i.e you have a token and you know what is it directly, and this without looking at the previous tokens (which is basically what parsing does, detect token patterns).
May 17 2017
parent reply MysticZach <reachzach ggmail.com> writes:
On Wednesday, 17 May 2017 at 09:57:41 UTC, Basile B. wrote:
 On Wednesday, 17 May 2017 at 09:53:49 UTC, MysticZach wrote:
 Option 4) Keep `body`, but make it both contextual *and* 
 optional. It becomes usable as an identifier, and those who 
 think it's unnecessary are appeased. The downside is that 
 different programmers will include it or not, based on 
 arbitrary preferences.
The problem with this option is the IDEs. D syntax so far doesn't require parsing to highlight, i.e you have a token and you know what is it directly, and this without looking at the previous tokens (which is basically what parsing does, detect token patterns).
I don't feel like it's much of a problem: 1. I suspect a simple matching of the three tokens '}', 'body', '{' would detect it most of the time. 2. Without that, remove `body` from your highlighter's list of keywords. When used as a keyword, it's very conspicuous anyway. Code won't lose much readability with just this one word unlit. 3. If `body` were optional, probably a lot of people wouldn't be using it to begin with. I suspect that Jonathan and I are not alone in thinking that it's not just useless, it's annoying. Thus, only code that uses it would have this problem.
May 17 2017
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, May 17, 2017 at 05:06:40PM +0000, MysticZach via Digitalmars-d wrote:
[...]
 3. If `body` were optional, probably a lot of people wouldn't be using
 it to begin with. I suspect that Jonathan and I are not alone in
 thinking that it's not just useless, it's annoying. Thus, only code
 that uses it would have this problem.
FWIW, I also find it annoying. Very annoying, in fact. The underlying gripe I have with it (apart from verbosity) is the asymmetry caused by the appearance of an extra(neous) keyword `body` in front of what is otherwise an undecorated {...} function body block, just because optional elements (in/out) were introduced. In other words, what irks me is that when there are no contracts, you have this: auto func(...) { /* code */ } But when there are contracts, not only do the contracts themselves appear (in {...} and/or out(...){...}), but an extraneous keyword `body` also appears. To put this in context, consider all the variations together: auto func(...) { /* code */ } auto func(...) in{...} body { /* code */ } auto func(...) out(...){...} body { /* code */ } auto func(...) in{...} out(...){...} body { /* code */ } Notice how the appearance of `body` in the 2nd to 4th lines sticks out like a sore thumb. Since in{...} and out(...){...} are optional elements, it would be more aesthetically pleasing if they did not also affect the syntax around them, e.g.: // Now they are truly optional, and the surrounding syntax // doesn't change by their presence/absence. auto func(...) { /* code */ } auto func(...) in{...} { /* code */ } auto func(...) out(...){...} { /* code */ } auto func(...) in{...} out(...){...} { /* code */ } Alternatively, the asymmetry would be eliminated if `body` was a *required* keyword before the function body, e.g.: auto func(...) body { /* code */ } auto func(...) in{...} body { /* code */ } auto func(...) out(...){...} body { /* code */ } auto func(...) in{...} out(...){...} body { /* code */ } But I doubt anyone here would agree to making `body` a required keyword when there are no contracts! T -- Unix is my IDE. -- Justin Whear
May 17 2017
prev sibling parent MysticZach <reachzach ggmail.com> writes:
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
 I think there are several issues at hand, and they need to be 
 dealt with individually:

 1. `body` is a very useful identifier. It would be nice to have 
 it available.

 2. Contract syntax is too verbose.

 3. a. Some people think code looks better with a keyword, e.g. 
 `body`, `do`, etc. distinguishing the function from the 
 contracts.

 3. b. Other people think that such a keyword is unnecessarily 
 redundant and does not justify its own existence.

 I think the thread will be more productive if the posters 
 commit to answering just one of these issues, and reserve other 
 issues for other threads. As the DIP in question is directly 

 problem and only that problem here.
I made a related DIP discussing issue 2, contract syntax is too verbose. The thread for discussing that one is here: http://forum.dlang.org/post/tuzdqqpcoguatepgxupq forum.dlang.org
May 23 2017
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 16 May 2017 at 18:06:38 UTC, Andrei Alexandrescu 
wrote:
 On 05/16/2017 01:59 PM, Random D user wrote:
 int foo()
 in
 {
 }
 out
 {
 }
 do
 {
   bar();
 }
Can't deny I like that. -- Andrei
I'll add this option to the DIP.
May 17 2017
parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
 On Tuesday, 16 May 2017 at 18:06:38 UTC, Andrei Alexandrescu 
 wrote:
 On 05/16/2017 01:59 PM, Random D user wrote:
 int foo()
 in
 {
 }
 out
 {
 }
 do
 {
   bar();
 }
Can't deny I like that. -- Andrei
I'll add this option to the DIP.
https://github.com/dlang/DIPs/pull/65
May 17 2017
parent reply MysticZach <reachzach ggmail.com> writes:
On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
 On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
 I'll add this option to the DIP.
https://github.com/dlang/DIPs/pull/65
I think ( http://forum.dlang.org/post/kybywnscisxpebezwyvk forum.dlang.org ) represents yet another distinct option. i.e. continue to allow `body`, but make it optional, that is, you can simply omit it if you want, while also allowing it as an identifier.
May 17 2017
next sibling parent MysticZach <reachzach ggmail.com> writes:
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
 http://forum.dlang.org/post/kybywnscisxpebezwyvk forum.dlang.org ) represents
yet another distinct option. i.e. continue to allow `body`, but make it
optional, that is, you can simply omit it if you want, while also allowing it
as an identifier.
For the record, this was first suggested by H. S. Teoh: http://forum.dlang.org/post/mailman.2204.1494612727.31550.digitalmars-d puremagic.com
May 18 2017
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
 On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
 On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
 I'll add this option to the DIP.
https://github.com/dlang/DIPs/pull/65
I think ( http://forum.dlang.org/post/kybywnscisxpebezwyvk forum.dlang.org ) represents yet another distinct option. i.e. continue to allow `body`, but make it optional, that is, you can simply omit it if you want, while also allowing it as an identifier.
This is pretty much the same as option 2. The short-term contextual part is covered by Walter's suggestion.
May 18 2017
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 18 May 2017 at 12:56:31 UTC, Meta wrote:
 On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
 On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
 On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
 I'll add this option to the DIP.
https://github.com/dlang/DIPs/pull/65
I think ( http://forum.dlang.org/post/kybywnscisxpebezwyvk forum.dlang.org ) represents yet another distinct option. i.e. continue to allow `body`, but make it optional, that is, you can simply omit it if you want, while also allowing it as an identifier.
This is pretty much the same as option 2. The short-term contextual part is covered by Walter's suggestion.
No it's not. What MysticZach suggests, and what I suggested even earlier [0] is to make 'body' contextual and optional which is very different than replacing it with another keyword. The main difference is that it would make code that uses contracts cleaner and there would be no breakage. In contrast, deprecating 'body' is a breaking change. IMO, option 2 and variations of it are *the worst* way forward. [0]: http://forum.dlang.org/post/pmldhzgcpuoydllfrbei forum.dlang.org
May 18 2017
parent MysticZach <reachzach ggmail.com> writes:
On Thursday, 18 May 2017 at 13:06:38 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Thursday, 18 May 2017 at 12:56:31 UTC, Meta wrote:
 This is pretty much the same as option 2. The short-term 
 contextual part is covered by Walter's suggestion.
No it's not. What MysticZach suggests, and what I suggested even earlier [0] is to make 'body' contextual and optional which is very different than replacing it with another keyword. The main difference is that it would make code that uses contracts cleaner and there would be no breakage. In contrast, deprecating 'body' is a breaking change. IMO, option 2 and variations of it are *the worst* way forward. [0]: http://forum.dlang.org/post/pmldhzgcpuoydllfrbei forum.dlang.org
Yes. Our proposal is actually a variation on option 3. Added to the current DIP, it would read: "Option 6: allow omitting `body`, and also allow it as an identifier" The two known downsides to this option so far are: 1. Different code will continue include the keyword version of `body` or not based on arbitrary programmer preferences. 2. Syntax highlighters that choose to highlight the word `body` will have to be modified to detect its different uses. Note that in the case of 1., strong preferences have been stated here for both styles, thus increasing the feeling that it's okay to allow both. Also note that the opposition to any inclusion of contextual keywords on principle is largely countered by the fact that there is no danger of semantic ambiguity between the two uses of `body` here.
May 18 2017
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 2017
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 2017
prev sibling next 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 2017
prev sibling next sibling parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
On 5/12/17 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. 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/fbb797f61ac92300eda1d63202157cd2a30b
555/DIPs/DIP1003.md 
 
 
 [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu forum.dlang.org
One possible substitute for the `function` keyword in option 2 could be `do`. I'm not convinced it's a good substitute, but I thought I'd throw it out there.
May 16 2017
parent Eugene Wissner <belka caraus.de> writes:
On Tuesday, 16 May 2017 at 16:10:56 UTC, David Gileadi wrote:
 One possible substitute for the `function` keyword in option 2 
 could be `do`. I'm not convinced it's a good substitute, but I 
 thought I'd throw it out there.
Looks weird for a C-style language imho.
May 16 2017
prev sibling next sibling parent reply 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
Before we go down endlessly debating which keywords would work best to replace body here, can someone please inform the crowd why just having body remain as it is now, but *not* be a keyword is unworkable? The more I think about it, the more I think that option 1 is the far far far superior option. Zero existing code breaks, and we now have access to our own body symbols (and we don't even have to go through a deprecation period). However, if there is a missing lynch pin that shows why this cannot work, then it's better to take it off the table now. -Steve
May 16 2017
parent reply Eugene Wissner <belka caraus.de> writes:
On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer 
wrote:
 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
Before we go down endlessly debating which keywords would work best to replace body here, can someone please inform the crowd why just having body remain as it is now, but *not* be a keyword is unworkable? The more I think about it, the more I think that option 1 is the far far far superior option. Zero existing code breaks, and we now have access to our own body symbols (and we don't even have to go through a deprecation period). However, if there is a missing lynch pin that shows why this cannot work, then it's better to take it off the table now. -Steve
1) Consistency with functions without contracts. 2) I wouldn't like to have body optional because: it introduces an additional style guide rule: there will be people who will omit it and people who will say: explicitely is better, always use body. 3) Syntax highlighting: Editors that work with regex will mark body in all contexts as a keyword. 4) I know body isn't reserved anywhere, I can use it without thinking abot the contexts (good for new comers who may think body is a reserved keyword if it is used as such in some contexts).
May 16 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/16/17 2:48 PM, Eugene Wissner wrote:
 On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer wrote:
 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
Before we go down endlessly debating which keywords would work best to replace body here, can someone please inform the crowd why just having body remain as it is now, but *not* be a keyword is unworkable? The more I think about it, the more I think that option 1 is the far far far superior option. Zero existing code breaks, and we now have access to our own body symbols (and we don't even have to go through a deprecation period). However, if there is a missing lynch pin that shows why this cannot work, then it's better to take it off the table now.
1) Consistency with functions without contracts.
This only applies to the "naked" version which has ugly }{ in it. The other options people are asking about are replacing body with a keyword, which I think you agree would be bad for consistency?
 2) I wouldn't like to have body optional because: it introduces an
 additional style guide rule: there will be people who will omit it and
 people who will say: explicitely is better, always use body.
Currently, body is required. It would still be required. Just not a keyword. I'm specifically asking if just removing the 'keyword-ness' of it is not doable for some reason. Note: body is optional for non-contract functions (yes, void foo() body { } is valid). I don't see a rash of people promoting having body there.
 3) Syntax highlighting: Editors that work with regex will mark body in
 all contexts as a keyword.
somewhere that's not inside a property, and see if it's highlighted differently.
 4) I know body isn't reserved anywhere, I can use it without thinking
 abot the contexts (good for new comers who may think body is a reserved
 keyword if it is used as such in some contexts).
I think maybe you misunderstand what I was asking. -Steve
May 16 2017
next sibling parent Eugene Wissner <belka caraus.de> writes:
On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer 
wrote:
 On 5/16/17 2:48 PM, Eugene Wissner wrote:
 On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer 
 wrote:

 1) Consistency with functions without contracts.
This only applies to the "naked" version which has ugly }{ in it. The other options people are asking about are replacing body with a keyword, which I think you agree would be bad for consistency?
Yeah, I think function or something else is a worse alternative. Better leave body as is than replace it with another word. I can name my variables body_ if I need.
 2) I wouldn't like to have body optional because: it 
 introduces an
 additional style guide rule: there will be people who will 
 omit it and
 people who will say: explicitely is better, always use body.
Currently, body is required. It would still be required. Just not a keyword. I'm specifically asking if just removing the 'keyword-ness' of it is not doable for some reason. Note: body is optional for non-contract functions (yes, void foo() body { } is valid). I don't see a rash of people promoting having body there.
I wasn't aware of it. Mea culpa.
 3) Syntax highlighting: Editors that work with regex will mark 
 body in
 all contexts as a keyword.
'set' somewhere that's not inside a property, and see if it's highlighted differently.
 4) I know body isn't reserved anywhere, I can use it without 
 thinking
 abot the contexts (good for new comers who may think body is a 
 reserved
 keyword if it is used as such in some contexts).
I think maybe you misunderstand what I was asking. -Steve
What I meant If I read a documentation on dlang.org that some identifier is reserved for some purpose I automatically think it can't be used as variable name. I don't want to check the list of reserved keywords every time I doubt. The same I never named my variables linux or Windows because they are used in version blocks. I have never tested if I can name my variable linux or Windows. Don't know if it makes sense.
May 16 2017
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 16.05.2017 21:25, Steven Schveighoffer wrote:
 I'm specifically asking if just removing the 'keyword-ness' of it is not
 doable for some reason.
It's easy to do technically. (The bad thing about option 1 is that it's the kind of thing that would probably not arise from an up-front language design and requires history to explain.)
May 16 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/16/17 3:43 PM, Timon Gehr wrote:
 On 16.05.2017 21:25, Steven Schveighoffer wrote:
 I'm specifically asking if just removing the 'keyword-ness' of it is not
 doable for some reason.
It's easy to do technically. (The bad thing about option 1 is that it's the kind of thing that would probably not arise from an up-front language design and requires history to explain.)
It's easy to explain. It looks better than just nothing between the two sets of braces :) -Steve
May 16 2017
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer 
wrote:
 1) Consistency with functions without contracts.
This only applies to the "naked" version which has ugly }{ in it. The other options people are asking about are replacing body with a keyword, which I think you agree would be bad for consistency?
I don't understand why this would be uglier than )( used in templates. Since imo it is one of the highlights of D to have "discovered" that one didn't need the super-ugly <> template pars of other languages, as the relative position in the code made it absolutely unambiguous which is which. The same is true for function bodies. It is completely unambiguous where it starts and ends. As for }{, it would be rare anyway, as it would generally be written vertically out { assert(whatever); } { ... } or even out { assert(whatever);} { ... }
May 17 2017
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/17/17 8:47 AM, Patrick Schluter wrote:
 On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer wrote:
 1) Consistency with functions without contracts.
This only applies to the "naked" version which has ugly }{ in it. The other options people are asking about are replacing body with a keyword, which I think you agree would be bad for consistency?
I don't understand why this would be uglier than )( used in templates. Since imo it is one of the highlights of D to have "discovered" that one didn't need the super-ugly <> template pars of other languages, as the relative position in the code made it absolutely unambiguous which is which.
Sure, it could be something we get used to. However, since naked {} are generally treated as a new scope and valid in many places, it looks strange.
 The same is true for function bodies. It is completely unambiguous where
 it starts and ends. As for }{, it would be rare anyway, as it would
 generally be written vertically
 out {
   assert(whatever);
 }
 {
 ....
 }

 or even

 out { assert(whatever);}
 {
  ...
 }
This has been hashed out in this thread quite a bit. It's a perception thing, not really a technical problem. And my perception is that it's ugly :) I think in practice, it would turn out probably fine. -Steve
May 17 2017
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 17.05.2017 14:47, Patrick Schluter wrote:

 I don't understand why this would be uglier than )( used in templates.
. This is a different case. In C-like languages '(' is essentially a binary operator and the second set of parens applies to the result of the first set. f(a)(b) is curried function application. The function body does not apply to the contract in any way, they are two syntactically independent constituents of the function declaration. (Clearly, function template declaration syntax would be better as "void foo!(A,B,C)(A a, B b, C c){ ... }", but fixing this is perhaps not an option now.)
May 17 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 17.05.2017 18:23, Timon Gehr wrote:
 On 17.05.2017 14:47, Patrick Schluter wrote:

 I don't understand why this would be uglier than )( used in templates.
. This is a different case. In C-like languages '(' is essentially a binary operator ...
Or rather, a postfix operator.
May 17 2017
prev sibling next sibling parent reply MysticZach <reachzach ggmail.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 believe the relevant discussion for this DIP can be simplified to just these two questions: 1. Should `body` be allowed as an identifier? 2. Should the keyword `body` remain as it is? But it's been demonstrated that these two issues do _not_ need to be decided together. Because there is no known possibility of semantic confusion between the two potential uses of `body`, the arguments against allowing `body` as a contextual keyword are reduced to two minor points: A. syntax highlighters will get confused B. some programmers consider contextual keywords to be "bad karma" It's possible to answer Question 1 based on these points alone. Only if one decides that the answer to Question 2 is "no" — i.e. that `body` as a keyword needs to change — does it open up the discussion on the various options for changing it. But that could technically be the subject of a different DIP.
May 25 2017
parent reply MysticZach <reachzach ggmail.com> writes:
On Thursday, 25 May 2017 at 11:49:47 UTC, MysticZach wrote:
 ...there is no known possibility of semantic confusion between 
 the two potential uses of `body`,
I spoke too soon. I found a place where such semantic ambiguity is possible. It can only occur in interface declarations, and will not exist in any currently compilable D code, as it requires `body` to be an identifier to be legal in the first place. Currently, the only place in D where you can declare a function that has a contract, but no body, is in an interface. D syntax, it turns out, does not require a semicolon at the end of such declarations. Referencing https://dlang.org/spec/interface.html#interface-contracts we have: interface I { int foo(int i) in { assert(i); } // <-- no semicolon required void bar(); } Therefore, with `body` as an identifier, you might have this ambiguity: struct body {} interface I { int foo(int i) in { assert(i); } body bar(); } The ambiguity is fixable by modifying the parser to look ahead after `body` for `{`. Since virtual interface functions are not even allowed to have bodies, if it finds `{`, then `body` should be interpreted as a keyword, and an error issued. In all other cases `body` should be interpreted as an identifier. This is not a hard problem, but it is indeed a semantic ambiguity, so it bears mentioning.
May 25 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.2017 20:57, MysticZach wrote:
 On Thursday, 25 May 2017 at 11:49:47 UTC, MysticZach wrote:
 ...there is no known possibility of semantic confusion between the two 
 potential uses of `body`,
I spoke too soon. I found a place where such semantic ambiguity is possible. It can only occur in interface declarations, and will not exist in any currently compilable D code, as it requires `body` to be an identifier to be legal in the first place. Currently, the only place in D where you can declare a function that has a contract, but no body, is in an interface. D syntax, it turns out, does not require a semicolon at the end of such declarations. Referencing https://dlang.org/spec/interface.html#interface-contracts we have: interface I { int foo(int i) in { assert(i); } // <-- no semicolon required void bar(); } Therefore, with `body` as an identifier, you might have this ambiguity: struct body {} interface I { int foo(int i) in { assert(i); } body bar(); } The ambiguity is fixable by modifying the parser to look ahead after `body` for `{`. Since virtual interface functions are not even allowed to have bodies, if it finds `{`, then `body` should be interpreted as a keyword, and an error issued. In all other cases `body` should be interpreted as an identifier. This is not a hard problem, but it is indeed a semantic ambiguity, so it bears mentioning.
There is no ambiguity, because only one valid interpretation exists.
May 25 2017
parent MysticZach <reachzach ggmail.com> writes:
On Friday, 26 May 2017 at 01:23:59 UTC, Timon Gehr wrote:
 On 25.05.2017 20:57, MysticZach wrote:
 struct body {}
 
 interface I {
    int foo(int i)
    in { assert(i); }
 
    body bar();
 }
 
 The ambiguity is fixable by modifying the parser to look ahead 
 after `body` for `{`. Since virtual interface functions are 
 not even allowed to have bodies, if it finds `{`, then `body` 
 should be interpreted as a keyword, and an error issued. In 
 all other cases `body` should be interpreted as an identifier.
 
 This is not a hard problem, but it is indeed a semantic 
 ambiguity, so it bears mentioning.
There is no ambiguity, because only one valid interpretation exists.
Well the parser needs to be aware of `body` here both as a keyword and as an identifier, and to use context to determine which one it is. So to me, that counts as a semantic ambiguity, one that is resolved trivially, by a single additional token. It doesn't seem like it lives up to a more generalized fear of having contextual keywords, unless it's like guy https://www.youtube.com/watch?v=tgj3nZWtOfA
May 25 2017
prev sibling parent Mike Parker <aldacron 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
The feedback period is complete. Thanks to all who participated. This will now go to Walter and Andrei for final evaluation. I'll report later on their decision.
May 26 2017