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