www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1003: remove `body` as a keyword

reply Dicebot <public dicebot.lv> writes:
DIP 1003 is merged to the queue and open for public informal 
feedback.

PR: https://github.com/dlang/DIPs/pull/48
Initial merged document: 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

If you want the change to be approved and have ideas how to 
improve it to better match on 
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and 
existing published reviews - please submit new PR with editorial 
and ping original author.
Nov 19 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 20/11/2016 10:16 AM, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to improve it
 to better match on
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing
 published reviews - please submit new PR with editorial and ping
 original author.


I'm not keen on the replacement syntax but I love the idea.

I was thinking maybe option 3 but not have the body first.

int func(int arg) {
	return 8 * arg;
} in {
	assert(arg > 0);
} out(int value) {
	assert(1);
}

Would break code but its a simple rearrangement.
Nov 19 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 20 Nov 2016 14:35:16 +1300, rikki cattermole wrote:

 I was thinking maybe option 3 but not have the body first.
 
 int func(int arg) {
 	return 8 * arg;
 } in {
 	assert(arg > 0);
 } out(int value) {
 	assert(1);
 }
 
 Would break code but its a simple rearrangement.


Right now, the normal flow when reading a function is:

* Doc comment: What did the author think important for me to know?
* Signature: How do I call it so the compiler will accept it?
* In contract: What sort of parameters are acceptable?
* Out contract: What invariants apply to the result?
* Body: I only need to read this if the rest didn't help.

This is ordered by importance.

By hanging the contracts off the end, you're making them harder to 
notice. That's not ideal.
Nov 20 2016
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal 
 feedback.


Perhaps a good idea for D3...
Nov 21 2016
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 19.11.2016 um 22:16 schrieb Dicebot:

 DIP 1003 is merged to the queue and open for public informal feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to improve it
 to better match on
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing
 published reviews - please submit new PR with editorial and ping
 original author.


I'd really like to see option 3, combined with option 1. The verbosity 
of the current syntax, as well as the sub-optimal contract semantics for 
classes*, make me personally almost always resort to normal assertions 
in the function body instead of using contracts.

That "body" is not available as an identifier is also quite annoying for 
certain applications. This is the case for a bunch of other keywords, 
too, but "body" as a keyword just has extremely little value, so it does 
stick out.

Really nice would be if "in" and "out" would then also take a general 
statement instead of just a block statement, so that a syntax like this 
would become possible for simple contracts:

     void foo(int a, int b)
       in assert(0 <= a && a < b);
       out(ret) assert(ret < b);
     {
       return b - 1 - a;
     }

The current equivalent just looks crowded and becomes hard to read, or 
wastes lots of vertical space if braces are put on their own line:

     void foo(int a, int b)
       in { assert(0 <= a && a < b); }
       out(ret) { assert(ret < b); }
     body {
       return b - 1 - a;
     }

For this whole proposal to work out, though, I think the old syntax will 
have to stay supported without deprecations, because the amount of 
breakage (the deprecation path won't change that) will otherwise 
probably be huge. Making "body" optional + contextual seems to be the 
way to go.

Since "body" is only used in a tiny and specific grammatical niche of 
the language, I also think that Walter's generic arguments form the 
linked thread don't really apply here, similar to "scope(...)" or 
"extern(...)".




* Example:

     interface Foo {
       void foo(int x) in { assert(x < 10); };
     }

     class Bar : Foo {
       // no contract enforced, because an omitted contract always
       // counts as a passing contract - need in { assert(false); } here
       override void foo(int x) { ... }
     }
Nov 21 2016
parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: DIP 1003: remove `body` as a keyword
References: <qgxvrbxrvkxtimzvnetu forum.dlang.org>
 <o0um1k$13lq$1 digitalmars.com>
In-Reply-To: <o0um1k$13lq$1 digitalmars.com>

--PTqtE9p4UwafcA4J0XIx7fNqO9e10OeMD
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/21/2016 01:33 PM, S=C3=B6nke Ludwig wrote:

 For this whole proposal to work out, though, I think the old syntax wil=


l

 have to stay supported without deprecations, because the amount of
 breakage (the deprecation path won't change that) will otherwise
 probably be huge. Making "body" optional + contextual seems to be the
 way to go.


Can you please elaborate on this? Deprecations don't break anything,
using -de flag for any stable project is a bug and misuse of compiler.
If we define deprecation term for contextual keyword to be several
years, the breakage will almost non-existent, much less than a regular
"bug fix breakage" from usual releases.



--PTqtE9p4UwafcA4J0XIx7fNqO9e10OeMD--
Nov 27 2016
prev sibling next sibling parent reply Piotrek <piotrek unknownuniverse.net> writes:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal 
 feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document: 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to 
 improve it to better match on 
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and 
 existing published reviews - please submit new PR with 
 editorial and ping original author.


How about this alternative ("in" and "out" blocks inside function 
body):

void foo(int a)
{
	in
	{
		assert (a > 0);
	}
	out
	{
		(ret) assert(ret > 0);
	}

	// body code

	return a;
}


or for one-liners:

void foo(int a)
{
	in assert (a > 0);
	out (ret) assert(ret > 0);

	// body code

	return a;
}

BR,
Piotrek
Nov 21 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 21.11.2016 17:55, Piotrek wrote:

 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to improve it
 to better match on
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing
 published reviews - please submit new PR with editorial and ping
 original author.


 How about this alternative ("in" and "out" blocks inside function body):

 void foo(int a)
 {
     in
     {
         assert (a > 0);
     }
     out
     {
         (ret) assert(ret > 0);
     }

     // body code

     return a;
 }


 or for one-liners:

 void foo(int a)
 {
     in assert (a > 0);
     out (ret) assert(ret > 0);

     // body code

     return a;
 }

 BR,
 Piotrek


Won't work. Contracts are part of the function signature. That's the point.
Nov 21 2016
parent Piotrek <piotrek unknownuniverse.net> writes:
On Monday, 21 November 2016 at 20:59:32 UTC, Timon Gehr wrote:

 How about this alternative ("in" and "out" blocks inside 
 function body):

 void foo(int a)
 {
     in
     {
         assert (a > 0);
     }
     out
     {
         (ret) assert(ret > 0);
     }

     // body code

     return a;
 }


 or for one-liners:

 void foo(int a)
 {
     in assert (a > 0);
     out (ret) assert(ret > 0);

     // body code

     return a;
 }

 BR,
 Piotrek


 Won't work. Contracts are part of the function signature. 
 That's the point.


How does "auto" work? Can't the inner in&out be applied to the 
signature?

BR,
Piotrek
Nov 21 2016
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 19.11.2016 22:16, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to improve it
 to better match on
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing
 published reviews - please submit new PR with editorial and ping
 original author.


I'm opposed to both option 2 and option 3 on the basis that they are 
both plain ugly (also, breaking), 2 is verbose, 3 is ambiguous. (Doing 
nothing is much better than 2 or 3.)

For option 1, the "on the basis that they will complicate the parser" 
argument is weak. Just lex 'body' as an identifier and expect to see 
that identifier in the parser. TOKbody occurs 4 times in DMD's parser, 
all of them are trivial to replace.
Nov 21 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 21.11.2016 um 22:19 schrieb Timon Gehr:

 3 is ambiguous.


Can you give an example?
Nov 22 2016
parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:

 Am 21.11.2016 um 22:19 schrieb Timon Gehr:

 3 is ambiguous.


 Can you give an example?


I'm curious as well. I considered that option 3 might be 
ambiguous but I managed to convince myself that it wouldn't be. 
I'm guessing you're referring to the fact that:

{
     //function body
}

Is a delegate literal, which could conceivably conflict with 
Option 3's syntax?

void fun(ref int n)
in { assert(n > 0); }
out { assert(n > 0); }
{ //Is this a syntax error or an immediately executed delegate 
literal?
     n += 1;
}()
Nov 22 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.11.2016 20:05, Meta wrote:

 On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:

 Am 21.11.2016 um 22:19 schrieb Timon Gehr:

 3 is ambiguous.


 Can you give an example?


 I'm curious as well. I considered that option 3 might be ambiguous but I
 managed to convince myself that it wouldn't be. I'm guessing you're
 referring to the fact that:

 {
     //function body
 }

 Is a delegate literal, which could conceivably conflict with Option 3's
 syntax?

 void fun(ref int n)
 in { assert(n > 0); }
 out { assert(n > 0); }
 { //Is this a syntax error or an immediately executed delegate literal?
     n += 1;
 }()



Function declarations don't necessarily have a body, but they might have 
contracts. (This is currently not allowed for technical reasons, but it 
should/will be.) But this is a rather minor point (usually you don't 
want to have contracts without implementation in a context where 
something starting with '{' is allowed).

The more important point is that there is no precedent where {...}{...} 
are two components of the same entity, it looks ugly even with the 
space-wasting convention where '{' is put on its own line. Not all 
contracts are one-liners like in your example above (which looks almost 
tolerable).
Nov 22 2016
next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 22.11.2016 um 23:37 schrieb Timon Gehr:

 On 22.11.2016 20:05, Meta wrote:

 On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:

 Am 21.11.2016 um 22:19 schrieb Timon Gehr:

 3 is ambiguous.


 Can you give an example?


 I'm curious as well. I considered that option 3 might be ambiguous but I
 managed to convince myself that it wouldn't be. I'm guessing you're
 referring to the fact that:

 {
     //function body
 }

 Is a delegate literal, which could conceivably conflict with Option 3's
 syntax?

 void fun(ref int n)
 in { assert(n > 0); }
 out { assert(n > 0); }
 { //Is this a syntax error or an immediately executed delegate literal?
     n += 1;
 }()



 Function declarations don't necessarily have a body, but they might have
 contracts. (This is currently not allowed for technical reasons, but it
 should/will be.) But this is a rather minor point (usually you don't
 want to have contracts without implementation in a context where
 something starting with '{' is allowed).


Okay, but that doesn't sound like there is a technical ambiguity here, 
then? Since there must be a full (block) statement after the in/out, it 
should always resolve naturally.


 The more important point is that there is no precedent where {...}{...}
 are two components of the same entity, it looks ugly even with the
 space-wasting convention where '{' is put on its own line. Not all
 contracts are one-liners like in your example above (which looks almost
 tolerable).


It can happen all the time with normal block statements. Especially 
something like 'scope' that works outside of the normal program flow has 
a certain similarity:

     scope (exit) { assert(n > 0); }
     {
         n += 1;
     }

What I personally dislike more is that adding something that should be 
an independent component of the function signature (e.g. an "int" 
contract) changes the syntax of the body definition. That always strikes 
me as an odd non-orthogonal part of the syntax.
Nov 23 2016
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 23.11.2016 11:15, Sönke Ludwig wrote:

 Function declarations don't necessarily have a body, but they might have
 contracts. (This is currently not allowed for technical reasons, but it
 should/will be.) But this is a rather minor point (usually you don't
 want to have contracts without implementation in a context where
 something starting with '{' is allowed).


 Okay, but that doesn't sound like there is a technical ambiguity here,
 then? Since there must be a full (block) statement after the in/out, it
 should always resolve naturally.


Technically, there is an ambiguity (technically, ambiguity means that 
there are multiple grammar derivations resulting in the same sentence).
Pragmatically, the greedy parse-the-body-if-possible-approach will work.
Nov 23 2016
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 23 November 2016 at 20:24:13 UTC, Timon Gehr wrote:

 Technically, there is an ambiguity (technically, ambiguity 
 means that there are multiple grammar derivations resulting in 
 the same sentence).
 Pragmatically, the greedy parse-the-body-if-possible-approach 
 will work.


I see no ambiguity even if parsing is not greedy.
Nov 24 2016
next sibling parent reply Kagamin <spam here.lot> writes:
As to contracts without body we have 
https://issues.dlang.org/show_bug.cgi?id=4720
Nov 24 2016
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 24.11.2016 10:47, Kagamin wrote:

 As to contracts without body we have
 https://issues.dlang.org/show_bug.cgi?id=4720


There is even this: https://github.com/dlang/dmd/pull/3611
(Only works for interfaces and abstract classes though. Note that the 
parser didn't change.)
Nov 25 2016
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.11.2016 10:24, Kagamin wrote:

 On Wednesday, 23 November 2016 at 20:24:13 UTC, Timon Gehr wrote:

 Technically, there is an ambiguity (technically, ambiguity means that
 there are multiple grammar derivations resulting in the same sentence).
 Pragmatically, the greedy parse-the-body-if-possible-approach will work.


 I see no ambiguity even if parsing is not greedy.


import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo()in{ assert(true); }{
     writeln("Hello World!");
}
void main(){
     static extern(C) void foo()in{ assert(true); }
     { foo(); }
}

Removing contracts, is this this code (printing "Hello World!"):

import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo(){
     writeln("Hello World!");
}
void main(){
     static extern(C) void foo();
     { foo(); }
}

Or this code (linker error):

import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo(){
     writeln("Hello World!");
}
void main(){
     static extern(C) void foo()
     { foo(); }
}
Nov 25 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 25.11.2016 um 12:39 schrieb Timon Gehr:

 On 24.11.2016 10:24, Kagamin wrote:

 I see no ambiguity even if parsing is not greedy.


 import std.stdio;
 pragma(mangle,"_D2tt4mainFZ3fooUZv")
 void foo()in{ assert(true); }{
     writeln("Hello World!");
 }
 void main(){
     static extern(C) void foo()in{ assert(true); }
     { foo(); }
 }

 Removing contracts, is this this code (printing "Hello World!"):

 import std.stdio;
 pragma(mangle,"_D2tt4mainFZ3fooUZv")
 void foo(){
     writeln("Hello World!");
 }
 void main(){
     static extern(C) void foo();
     { foo(); }
 }


Not without explicitly adding that ";".
Nov 25 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 25.11.2016 22:18, Sönke Ludwig wrote:

 Am 25.11.2016 um 12:39 schrieb Timon Gehr:

 On 24.11.2016 10:24, Kagamin wrote:

 I see no ambiguity even if parsing is not greedy.


 import std.stdio;
 pragma(mangle,"_D2tt4mainFZ3fooUZv")
 void foo()in{ assert(true); }{
     writeln("Hello World!");
 }
 void main(){
     static extern(C) void foo()in{ assert(true); }
     { foo(); }
 }

 Removing contracts, is this this code (printing "Hello World!"):

 import std.stdio;
 pragma(mangle,"_D2tt4mainFZ3fooUZv")
 void foo(){
     writeln("Hello World!");
 }
 void main(){
     static extern(C) void foo();
     { foo(); }
 }


 Not without explicitly adding that ";".


?

The point here was to illustrate what the two possible interpretations 
are in terms of code that is compatible with current D. The syntax for 
body-less function declarations with contracts proposed in pull 3611 [1] 
does not require a ';' to be present.

[1] https://github.com/dlang/dmd/pull/3611

The interpretation you are complaining about is in fact the standard 
interpretation without option 3, but with contracts on function 
declarations.
Nov 25 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 25.11.2016 um 23:28 schrieb Timon Gehr:

 On 25.11.2016 22:18, Sönke Ludwig wrote:

 Am 25.11.2016 um 12:39 schrieb Timon Gehr:

 On 24.11.2016 10:24, Kagamin wrote:

 I see no ambiguity even if parsing is not greedy.


 import std.stdio;
 pragma(mangle,"_D2tt4mainFZ3fooUZv")
 void foo()in{ assert(true); }{
     writeln("Hello World!");
 }
 void main(){
     static extern(C) void foo()in{ assert(true); }
     { foo(); }
 }

 Removing contracts, is this this code (printing "Hello World!"):

 import std.stdio;
 pragma(mangle,"_D2tt4mainFZ3fooUZv")
 void foo(){
     writeln("Hello World!");
 }
 void main(){
     static extern(C) void foo();
     { foo(); }
 }


 Not without explicitly adding that ";".


 ?

 The point here was to illustrate what the two possible interpretations
 are in terms of code that is compatible with current D. The syntax for
 body-less function declarations with contracts proposed in pull 3611 [1]
 does not require a ';' to be present.

 [1] https://github.com/dlang/dmd/pull/3611

 The interpretation you are complaining about is in fact the standard
 interpretation without option 3, but with contracts on function
 declarations.


Okay, *that's* the missing piece, thanks for clarifying. I somehow 
expected that function declarations would always have to end with a 
semicolon. But admittedly, even then, with my proposal to allow 
non-block statements for contracts, that would still leave this 
ambiguity for local function declarations.

The same mechanic unfortunately also makes the "do" suggestion annoying 
to implement.
Nov 25 2016
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 23.11.2016 11:15, Sönke Ludwig wrote:

 The more important point is that there is no precedent where {...}{...}
 are two components of the same entity, it looks ugly even with the
 space-wasting convention where '{' is put on its own line. Not all
 contracts are one-liners like in your example above (which looks almost
 tolerable).


 It can happen all the time with normal block statements. Especially
 something like 'scope' that works outside of the normal program flow has
 a certain similarity:

     scope (exit) { assert(n > 0); }
     {
         n += 1;
     }


This is not a counterexample, because the block statement following the 
scope statement is not part of the scope statement. I.e. if anything, it 
is bad that this looks similar, because it is grammatically different.

(Also, in my code there are usually exactly zero block statements nested 
directly in block statements.)
Nov 23 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 23.11.2016 um 21:32 schrieb Timon Gehr:

 On 23.11.2016 11:15, Sönke Ludwig wrote:

     scope (exit) { assert(n > 0); }
     {
         n += 1;
     }


 This is not a counterexample, because the block statement following the
 scope statement is not part of the scope statement. I.e. if anything, it
 is bad that this looks similar, because it is grammatically different.


The function body isn't part of the "in"/"out" contract either. I don't 
see the point here.


 (Also, in my code there are usually exactly zero block statements nested
 directly in block statements.)


The whole topic in general so far seems to be mainly hinged around 
personal taste (me included). Not sure if we'll be able to reach consent 
for anything but option 1.
Nov 24 2016
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 24.11.2016 12:35, Sönke Ludwig wrote:

 Am 23.11.2016 um 21:32 schrieb Timon Gehr:

 On 23.11.2016 11:15, Sönke Ludwig wrote:

     scope (exit) { assert(n > 0); }
     {
         n += 1;
     }


 This is not a counterexample, because the block statement following the
 scope statement is not part of the scope statement. I.e. if anything, it
 is bad that this looks similar, because it is grammatically different.


 The function body isn't part of the "in"/"out" contract either. I don't
 see the point here.
 ...


There can be no free-standing contract, it's part of the function signature.


 (Also, in my code there are usually exactly zero block statements nested
 directly in block statements.)


 The whole topic in general so far seems to be mainly hinged around
 personal taste (me included). Not sure if we'll be able to reach consent
 for anything but option 1.


That's understood (this is about syntax).

BTW, a point against option 2 is: "body" is actually one of the few 
keywords that D has that have adequate names. It's the body that 
follows, not the function.
Nov 24 2016
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 22 November 2016 at 22:37:03 UTC, Timon Gehr wrote:

 The more important point is that there is no precedent where 
 {...}{...} are two components of the same entity, it looks ugly 
 even with the space-wasting convention where '{' is put on its 
 own line. Not all contracts are one-liners like in your example 
 above (which looks almost tolerable).


Templated functions have
T!( .... lots and lots of stuff .... ) f!( .... lots and lots of 
stuff .... )( .... lots and lots of stuff .... ) if ( .... lots 
and lots of stuff .... )

And yes, it's ugly.
Nov 23 2016
parent Kagamin <spam here.lot> writes:
Must be
T!( .... lots and lots of stuff .... ) f( .... lots and lots of 
stuff .... )( .... lots and lots of stuff .... ) if ( .... lots 
and lots of stuff .... )
Nov 23 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
int div(int a, int b)
in { assert(b != 0); }
do
{
     return a / b;
}
Nov 23 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Saturday, November 19, 2016 21:16:15 Dicebot via Digitalmars-d-announce 
wrote:

 DIP 1003 is merged to the queue and open for public informal
 feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to
 improve it to better match on
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and
 existing published reviews - please submit new PR with editorial
 and ping original author.


Personally, I don't care much about having body as a usable symbol. It
occasionally would be useful, but I can live without it. However, I _do_
find it very annoying that it's required for the function body when you have
contracts. After all, it's not required when you write the function
normally. Why should it be required when you have contracts on the function?
The braces after the contracts are clearly for the function body. They
couldn't be for anything else. The compiler always requires that the body be
last after the in and out contracts, making the body keyword totally
redundant. So, I've never understood why the body keyword was required. As
far as I can tell, it fixes no ambiguity. It's just extra typing, and it
makes contracts that much more verbose, which makes me that much more
inclined to just not bother with them and put the assertions in the function
body - particularly when I'm already of the opinion that they add no value
outside of inheritance, because assertions at the beginning of the function
take care of in contracts, and unit tests are really what covers the out
contract case anyway (particularly since it's very rare that you can have a
general test for the out contract rather than testing that specific input
results in specific output).

That being said, I don't care about option 1. Adding a contextual keyword
just to get the body keyword is not worth the tradeoff as far as I'm
concerned.

Option 2 is also pointless IMHO, because you _still_ have a pointless
keyword sitting on the function body. All it's doing is trying to get the
body keyword back for general use, which might be nice, but it seems to me
that the important thing here is to get rid of the pointless and annoying
keyword on the function body, and swapping one keyword for another, longer
keyword is most definitely not an improvement in that regard.

IMHO, option 3 is what we should have done ages ago. Even if the keyword had
been something like xyzzy rather than something that a number of folks want
to use for a symbol name, it still shouldn't have been there, because it
adds no value and helps to make contracts even more verbose.

- Jonathan M Davis
Nov 24 2016
parent Mark <smarksc gmail.com> writes:
On Thursday, 24 November 2016 at 14:06:40 UTC, Jonathan M Davis 
wrote:

 Personally, I don't care much about having body as a usable 
 symbol. It occasionally would be useful, but I can live without 
 it. However, I _do_ find it very annoying that it's required 
 for the function body when you have contracts. After all, it's 
 not required when you write the function normally. Why should 
 it be required when you have contracts on the function? The 
 braces after the contracts are clearly for the function body. 
 They couldn't be for anything else. The compiler always 
 requires that the body be last after the in and out contracts, 
 making the body keyword totally redundant. So, I've never 
 understood why the body keyword was required. As far as I can 
 tell, it fixes no ambiguity. It's just extra typing, and it 
 makes contracts that much more verbose, which makes me that 
 much more inclined to just not bother with them and put the 
 assertions in the function body - particularly when I'm already 
 of the opinion that they add no value outside of inheritance, 
 because assertions at the beginning of the function take care 
 of in contracts, and unit tests are really what covers the out 
 contract case anyway (particularly since it's very rare that 
 you can have a general test for the out contract rather than 
 testing that specific input results in specific output).

 - Jonathan M Davis


General tests of output are not so rare. The premise of 
property-based testing is being able to write such tests. Going 
over the functions in std.algorithm, for almost every one of them 
I can find a nontrivial property that any output should satisfy 
(for a valid input).
Dec 13 2016
prev sibling next sibling parent meppl <mephisto nordhoff-online.de> writes:
Indentation syntax

If we have an optional indentation syntax one day, those 
anonymous looking scopes behind functions may become weird things.

int div(int a, int b)
in { assert(b != 0); }
{
     return a / b;
}

indentation:

int div( int a, int b)
in:
     assert( b != 0)
:
     return a / b



And i like two proposals of this thread here who are not part of 
the DIP:


Kagamin's proposal to just use a shorter keyword than "body" or 
"function".


 int div(int a, int b)
 in { assert(b != 0); }
 do
 {
     return a / b;
 }



Sönke Ludwigs suggestion:


 Really nice would be if "in" and "out" would then also take a 
 general statement instead of just a block statement, so that a 
 syntax like this would become possible for simple contracts:
 
     void foo(int a, int b)
       in assert(0 <= a && a < b);
       out(ret) assert(ret < b);
     {
       return b - 1 - a;
     }
Nov 24 2016
prev sibling next sibling parent reply WM.H <WMH nowhere.fi> writes:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal 
 feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document: 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to 
 improve it to better match on 
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and 
 existing published reviews - please submit new PR with 
 editorial and ping original author.


This DIP fixes the problem for "body" but not for the other 
keywords. After all the problem may exist for other keywords. Was 
a new pragma considered ? For example an identifier alias.

pragma(idAlias, "body", "body_" )

would mean that any "body_" will be treated as "body" identifier. 
The translation would happen just after the grammatical parsing, 
because at this phase keywords don't matter anymore.

example:

====
module module_;

pragma(idAlias, "function", "function_" );
pragma(idAlias, "module", "module_" )

int function_()
{
     pragma(msg, __PRETTY_FUNCTION__);
     return 0;
}
====

prints "int module.function()" during compilation.
Nov 24 2016
parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: DIP 1003: remove `body` as a keyword
References: <qgxvrbxrvkxtimzvnetu forum.dlang.org>
 <tbfmrgibgbkrjlctovht forum.dlang.org>
In-Reply-To: <tbfmrgibgbkrjlctovht forum.dlang.org>

--HAVVuwSw737gQrHIaWVmT179AtP5eAlNw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/24/2016 05:29 PM, WM.H wrote:

 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal feedback.=





 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to improve it=





 to better match on
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing
 published reviews - please submit new PR with editorial and ping
 original author.


=20
 This DIP fixes the problem for "body" but not for the other keywords.
 After all the problem may exist for other keywords. Was a new pragma
 considered ? For example an identifier alias.
=20
 pragma(idAlias, "body", "body_" )


AFAIU, the point of this DIP is that "body" is standing out from other
keywords being used only in one very specific context and being a very
common english word at the same time. Your proposal has a completely
different (and much more drastic) approach.


--HAVVuwSw737gQrHIaWVmT179AtP5eAlNw--
Nov 27 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:

 On 11/24/2016 05:29 PM, WM.H wrote:

 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal 
 feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to 
 improve it to better match on 
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and 
 existing published reviews - please submit new PR with 
 editorial and ping original author.


 
 This DIP fixes the problem for "body" but not for the other 
 keywords. After all the problem may exist for other keywords. 
 Was a new pragma considered ? For example an identifier alias.
 
 pragma(idAlias, "body", "body_" )


 AFAIU, the point of this DIP is that "body" is standing out 
 from other keywords being used only in one very specific 
 context and being a very common english word at the same time. 
 Your proposal has a completely different (and much more 
 drastic) approach.


Yes. But while it's clear that "body" is a keyword that's less 
related to programming languages than the others (i.e more usable 
as identifier), it's not actually that mad to imagine a generic 
approach. For example Object Pascal has such a feature:

http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_for_.26-escaping_of_keywords

which is not well known, as I've myself discovered this just 3 
minutes ago.

could serve to escape keywords, while still considering them as 
identifier when it's needed, e.g

struct Body{}
Body #body;
writeln("'", #body.stringof, "'");

would output: 'body'
Dec 10 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:

 On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:

 On 11/24/2016 05:29 PM, WM.H wrote:

 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal 
 feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to 
 improve it to better match on 
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and 
 existing published reviews - please submit new PR with 
 editorial and ping original author.


 
 This DIP fixes the problem for "body" but not for the other 
 keywords. After all the problem may exist for other keywords. 
 Was a new pragma considered ? For example an identifier alias.
 
 pragma(idAlias, "body", "body_" )


 AFAIU, the point of this DIP is that "body" is standing out 
 from other keywords being used only in one very specific 
 context and being a very common english word at the same time. 
 Your proposal has a completely different (and much more 
 drastic) approach.


 Yes. But while it's clear that "body" is a keyword that's less 
 related to programming languages than the others (i.e more 
 usable as identifier), it's not actually that mad to imagine a 
 generic approach. For example Object Pascal has such a feature:

 http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_for_.26-escaping_of_keywords

 which is not well known, as I've myself discovered this just 3 
 minutes ago.

 could serve to escape keywords, while still considering them as 
 identifier when it's needed, e.g

 struct Body{}
 Body #body;
 writeln("'", #body.stringof, "'");

 would output: 'body'


By the way a pragma was a bad idea. Pragmas are optionally 
supported by a compiler. An escape symbol is by far better. 
Whatever is the compiler we always want the same result.

Any chance to get "Cauterite" thoughts on the option that is to 
have a token used to escape a keyword, so that the kw can be used 
as identifier ?

The initial DIP is too specialized, however it shows a real 
problem:

What if one day someone wants

     enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
     function Function;

With an escape it would always work

     enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
     #function Function;

The problem of the suffix "_", as proposed in D style guide, is 


sequences !

- body = token
=> #body is a special token sequence.

The only thing to change is that currently a special token 
sequence takes a full line...but seriously that's a minor change 
(since there's no special token sequence in D... #line is 
obsolete and not used anymore).
Dec 10 2016
parent reply Rory McGuire via Digitalmars-d-announce writes:
On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:


 On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:


 On 11/24/2016 05:29 PM, WM.H wrote:


 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:


 DIP 1003 is merged to the queue and open for public informal feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to improve it
 to better match on https://github.com/dlang/DIPs/
 blob/master/GUIDELINES.md and existing published reviews - please
 submit new PR with editorial and ping original author.


 This DIP fixes the problem for "body" but not for the other keywords.
 After all the problem may exist for other keywords. Was a new pragma
 considered ? For example an identifier alias.

 pragma(idAlias, "body", "body_" )


 AFAIU, the point of this DIP is that "body" is standing out from other
 keywords being used only in one very specific context and being a very
 common english word at the same time. Your proposal has a completely
 different (and much more drastic) approach.


 Yes. But while it's clear that "body" is a keyword that's less related to
 programming languages than the others (i.e more usable as identifier), it's
 not actually that mad to imagine a generic approach. For example Object
 Pascal has such a feature:

 http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_
 for_.26-escaping_of_keywords

 which is not well known, as I've myself discovered this just 3 minutes
 ago.

 serve to escape keywords, while still considering them as identifier when
 it's needed, e.g

 struct Body{}
 Body #body;
 writeln("'", #body.stringof, "'");

 would output: 'body'


 By the way a pragma was a bad idea. Pragmas are optionally supported by a
 compiler. An escape symbol is by far better. Whatever is the compiler we
 always want the same result.

 Any chance to get "Cauterite" thoughts on the option that is to have a
 token used to escape a keyword, so that the kw can be used as identifier ?

 The initial DIP is too specialized, however it shows a real problem:

 What if one day someone wants

     enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
     function Function;

 With an escape it would always work

     enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
     #function Function;

 The problem of the suffix "_", as proposed in D style guide, is that it's

 role is already for special token sequences !

 - body = token
 => #body is a special token sequence.

 The only thing to change is that currently a special token sequence takes
 a full line...but seriously that's a minor change (since there's no special
 token sequence in D... #line is obsolete and not used anymore).


Why is #line obsolete? I use it a lot in string mixins to make the correct
line numbers show.

Thanks!
Dec 10 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 11 December 2016 at 07:52:28 UTC, Rory McGuire wrote:

 On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via 
 Digitalmars-d-announce < digitalmars-d-announce puremagic.com> 
 wrote:


 On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:


 On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:


 On 11/24/2016 05:29 PM, WM.H wrote:


 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot 
 wrote:


 DIP 1003 is merged to the queue and open for public 
 informal feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how 
 to improve it to better match on 
 https://github.com/dlang/DIPs/ blob/master/GUIDELINES.md 
 and existing published reviews - please submit new PR with 
 editorial and ping original author.


 This DIP fixes the problem for "body" but not for the other 
 keywords. After all the problem may exist for other 
 keywords. Was a new pragma considered ? For example an 
 identifier alias.

 pragma(idAlias, "body", "body_" )


 AFAIU, the point of this DIP is that "body" is standing out 
 from other keywords being used only in one very specific 
 context and being a very common english word at the same 
 time. Your proposal has a completely different (and much 
 more drastic) approach.


 Yes. But while it's clear that "body" is a keyword that's 
 less related to programming languages than the others (i.e 
 more usable as identifier), it's not actually that mad to 
 imagine a generic approach. For example Object Pascal has 
 such a feature:

 http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_ 
 for_.26-escaping_of_keywords

 which is not well known, as I've myself discovered this just 
 3 minutes
 ago.

 which could
 serve to escape keywords, while still considering them as 
 identifier when
 it's needed, e.g

 struct Body{}
 Body #body;
 writeln("'", #body.stringof, "'");

 would output: 'body'


 By the way a pragma was a bad idea. Pragmas are optionally 
 supported by a compiler. An escape symbol is by far better. 
 Whatever is the compiler we always want the same result.

 Any chance to get "Cauterite" thoughts on the option that is 
 to have a token used to escape a keyword, so that the kw can 
 be used as identifier ?

 The initial DIP is too specialized, however it shows a real 
 problem:

 What if one day someone wants

     enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
     function Function;

 With an escape it would always work

     enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
     #function Function;

 The problem of the suffix "_", as proposed in D style guide, 
 is that it's


 role is already for special token sequences !

 - body = token
 => #body is a special token sequence.

 The only thing to change is that currently a special token 
 sequence takes a full line...but seriously that's a minor 
 change (since there's no special token sequence in D... #line 
 is obsolete and not used anymore).


 Why is #line obsolete? I use it a lot in string mixins to make 
 the correct line numbers show.


In the compiler it is. Last Fall I asked and I've got for reply 
that is was useful in the past to debug mixins, in the compiler 
itself. I didn't know that people use it. Anyway it doesn't 
change anything.

DIP 1003 is faddish. It would really be better to have a system 
that would allow any keyword to be used as identifier. An escape 
system is the key.
Dec 11 2016
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:

 On Sunday, 11 December 2016 at 07:52:28 UTC, Rory McGuire wrote:

 On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via 
 Digitalmars-d-announce < digitalmars-d-announce puremagic.com> 
 wrote:


[...]


 Why is #line obsolete? I use it a lot in string mixins to make 
 the correct line numbers show.


 In the compiler it is. Last Fall I asked and I've got for reply 
 that is was useful in the past to debug mixins, in the compiler 
 itself. I didn't know that people use it. Anyway it doesn't 
 change anything.

 DIP 1003 is faddish. It would really be better to have a system 
 that would allow any keyword to be used as identifier. An 
 escape system is the key.


It would also allow to interface to libs written in another 
language exporting a D keyword as symbol. I have no example here 
but I can imagine this happening quite easily.
Dec 11 2016
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:

 DIP 1003 is faddish. It would really be better to have a system 
 that would allow any keyword to be used as identifier. An 
 escape system is the key.


It would also guarantee that the DIP would not be accepted. With 
this DIP I aimed for the smallest possible change that would 
alleviate the problem of not being able to use `body` as a symbol 
name, hoping that the smallness of the problem and ease of 
implementation would make it much more likely to be accepted.
Dec 11 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 11 December 2016 at 20:27:36 UTC, Meta wrote:

 On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:

 DIP 1003 is faddish. It would really be better to have a 
 system that would allow any keyword to be used as identifier. 
 An escape system is the key.


 It would also guarantee that the DIP would not be accepted. 
 With this DIP I aimed


Sorry in a previous post there's been a confusion from my part, I 
thought the author was "Cauterite".


 for the smallest possible change that would alleviate the 
 problem of not being able to use `body` as a symbol name, 
 hoping that the smallness of the problem and ease of 
 implementation would make it much more likely to be accepted.


I won't insist too much but to be clear, the escape solution is 
incredibly simple to implement (7 SLOC !). I've decided to go 
further in order to demonstrate it:

https://github.com/dlang/dmd/pull/6324
Dec 15 2016
next sibling parent reply Namespace <rswhite4 gmail.com> writes:
On Thursday, 15 December 2016 at 15:31:40 UTC, Basile B. wrote:

 On Sunday, 11 December 2016 at 20:27:36 UTC, Meta wrote:

 On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:

 DIP 1003 is faddish. It would really be better to have a 
 system that would allow any keyword to be used as identifier. 
 An escape system is the key.


 It would also guarantee that the DIP would not be accepted. 
 With this DIP I aimed


 Sorry in a previous post there's been a confusion from my part, 
 I thought the author was "Cauterite".


 for the smallest possible change that would alleviate the 
 problem of not being able to use `body` as a symbol name, 
 hoping that the smallness of the problem and ease of 
 implementation would make it much more likely to be accepted.


 I won't insist too much but to be clear, the escape solution is 
 incredibly simple to implement (7 SLOC !). I've decided to go 
 further in order to demonstrate it:

 https://github.com/dlang/dmd/pull/6324



http://forum.dlang.org/thread/fiwfcsqmjsndcjixipgz forum.dlang.org

Two birds - one stone (;
Dec 15 2016
parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 15 December 2016 at 18:44:42 UTC, Namespace wrote:

 On Thursday, 15 December 2016 at 15:31:40 UTC, Basile B. wrote:

 On Sunday, 11 December 2016 at 20:27:36 UTC, Meta wrote:

 On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:

 DIP 1003 is faddish. It would really be better to have a 
 system that would allow any keyword to be used as 
 identifier. An escape system is the key.


 It would also guarantee that the DIP would not be accepted. 
 With this DIP I aimed


 Sorry in a previous post there's been a confusion from my 
 part, I thought the author was "Cauterite".


 for the smallest possible change that would alleviate the 
 problem of not being able to use `body` as a symbol name, 
 hoping that the smallness of the problem and ease of 
 implementation would make it much more likely to be accepted.


 I won't insist too much but to be clear, the escape solution 
 is incredibly simple to implement (7 SLOC !). I've decided to 
 go further in order to demonstrate it:

 https://github.com/dlang/dmd/pull/6324



 http://forum.dlang.org/thread/fiwfcsqmjsndcjixipgz forum.dlang.org


Irony I suppose ?


 Two birds - one stone (;



4 of 
http://forum.dlang.org/post/lllbfrmrhsjafijloadg forum.dlang.org) 
then #const like in PR 6324 doesn't work...anyway one of the idea 
is more concrete than the other. ;)
Dec 15 2016
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 15 December 2016 at 15:31:40 UTC, Basile B. wrote:

 On Sunday, 11 December 2016 at 20:27:36 UTC, Meta wrote:

 On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:

 DIP 1003 is faddish. It would really be better to have a 
 system that would allow any keyword to be used as identifier. 
 An escape system is the key.


 It would also guarantee that the DIP would not be accepted. 
 With this DIP I aimed


 Sorry in a previous post there's been a confusion from my part, 
 I thought the author was "Cauterite".


 for the smallest possible change that would alleviate the 
 problem of not being able to use `body` as a symbol name, 
 hoping that the smallness of the problem and ease of 
 implementation would make it much more likely to be accepted.


 I won't insist too much but to be clear, the escape solution is 
 incredibly simple to implement (7 SLOC !). I've decided to go 
 further in order to demonstrate it:

 https://github.com/dlang/dmd/pull/6324


I saw your PR but I don't really agree that it's a good solution. 

just use a trailing underscore, like "body_".
Dec 15 2016
parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 15 December 2016 at 21:19:30 UTC, Meta wrote:

 On Thursday, 15 December 2016 at 15:31:40 UTC, Basile B. wrote:

 On Sunday, 11 December 2016 at 20:27:36 UTC, Meta wrote:

 On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:

 DIP 1003 is faddish. It would really be better to have a 
 system that would allow any keyword to be used as 
 identifier. An escape system is the key.


 It would also guarantee that the DIP would not be accepted. 
 With this DIP I aimed


 Sorry in a previous post there's been a confusion from my 
 part, I thought the author was "Cauterite".


 for the smallest possible change that would alleviate the 
 problem of not being able to use `body` as a symbol name, 
 hoping that the smallness of the problem and ease of 
 implementation would make it much more likely to be accepted.


 I won't insist too much but to be clear, the escape solution 
 is incredibly simple to implement (7 SLOC !). I've decided to 
 go further in order to demonstrate it:

 https://github.com/dlang/dmd/pull/6324


 I saw your PR but I don't really agree that it's a good 

 might as well just use a trailing underscore, like "body_".


No, there are 2 differences.

- 1: even if in the source you write #body, the identifier, as 
known by the compiler, is really just "body", like shown in the 
test that uses `pragma(identifier)`. For example a serializer 
would write "body" without any kind of processing (unlike what 's 
to be done using the basic underscore solution).


cannot distinguish a keyword suffixed with an underscore because 
it might be intentional, i.e part of the identifier.
Dec 15 2016
prev sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal 
 feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document: 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to 
 improve it to better match on 
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and 
 existing published reviews - please submit new PR with 
 editorial and ping original author.


Bump, if that makes sense.
Dec 30 2016
parent Dicebot <public dicebot.lv> writes:
On Saturday, 31 December 2016 at 01:14:23 UTC, Arun 
Chandrasekaran wrote:

 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

 DIP 1003 is merged to the queue and open for public informal 
 feedback.

 PR: https://github.com/dlang/DIPs/pull/48
 Initial merged document: 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

 If you want the change to be approved and have ideas how to 
 improve it to better match on 
 https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and 
 existing published reviews - please submit new PR with 
 editorial and ping original author.


 Bump, if that makes sense.


I have asked DIP author if he plans any last moment modifications 
and will try to schedule it for review in January.
Jan 02 2017