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