DIP 1003: remove `body` as a keyword

2016-11-19 Thread Dicebot via Digitalmars-d-announce
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.


Re: DIP 1003: remove `body` as a keyword

2016-11-19 Thread rikki cattermole via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-20 Thread Chris Wright via Digitalmars-d-announce
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.


Re: DIP 1003: remove `body` as a keyword

2016-11-21 Thread Dejan Lekic via Digitalmars-d-announce

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...


Re: DIP 1003: remove `body` as a keyword

2016-11-21 Thread Sönke Ludwig via Digitalmars-d-announce

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) { ... }
}



Re: DIP 1003: remove `body` as a keyword

2016-11-21 Thread Piotrek via Digitalmars-d-announce

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


Re: DIP 1003: remove `body` as a keyword

2016-11-21 Thread Timon Gehr via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-21 Thread Timon Gehr via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-21 Thread Piotrek via Digitalmars-d-announce

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


Re: DIP 1003: remove `body` as a keyword

2016-11-22 Thread Sönke Ludwig via Digitalmars-d-announce

Am 21.11.2016 um 22:19 schrieb Timon Gehr:

3 is ambiguous.


Can you give an example?



Re: DIP 1003: remove `body` as a keyword

2016-11-22 Thread Meta via Digitalmars-d-announce

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;
}()


Re: DIP 1003: remove `body` as a keyword

2016-11-22 Thread Timon Gehr via Digitalmars-d-announce

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).


Re: DIP 1003: remove `body` as a keyword

2016-11-23 Thread Sönke Ludwig via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-23 Thread Kagamin via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-23 Thread Kagamin via Digitalmars-d-announce

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


Re: DIP 1003: remove `body` as a keyword

2016-11-23 Thread Kagamin via Digitalmars-d-announce

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  )


Re: DIP 1003: remove `body` as a keyword

2016-11-23 Thread Timon Gehr via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-23 Thread Timon Gehr via Digitalmars-d-announce

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.)


Re: DIP 1003: remove `body` as a keyword

2016-11-24 Thread Kagamin via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-24 Thread Kagamin via Digitalmars-d-announce
As to contracts without body we have 
https://issues.dlang.org/show_bug.cgi?id=4720


Re: DIP 1003: remove `body` as a keyword

2016-11-24 Thread Sönke Ludwig via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-24 Thread Jonathan M Davis via Digitalmars-d-announce
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



Re: DIP 1003: remove `body` as a keyword

2016-11-24 Thread meppl via Digitalmars-d-announce

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;
}




Re: DIP 1003: remove `body` as a keyword

2016-11-24 Thread WM.H via Digitalmars-d-announce

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.



Re: DIP 1003: remove `body` as a keyword

2016-11-24 Thread Timon Gehr via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-25 Thread Timon Gehr via Digitalmars-d-announce

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.)


Re: DIP 1003: remove `body` as a keyword

2016-11-25 Thread Timon Gehr via Digitalmars-d-announce

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(); }
}



Re: DIP 1003: remove `body` as a keyword

2016-11-25 Thread Sönke Ludwig via Digitalmars-d-announce

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 ";".


Re: DIP 1003: remove `body` as a keyword

2016-11-25 Thread Timon Gehr via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-25 Thread Sönke Ludwig via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-11-27 Thread Dicebot via Digitalmars-d-announce
On 11/21/2016 01:33 PM, Sönke Ludwig wrote:
> 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.

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.




signature.asc
Description: OpenPGP digital signature


Re: DIP 1003: remove `body` as a keyword

2016-11-27 Thread Dicebot via Digitalmars-d-announce
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.



signature.asc
Description: OpenPGP digital signature


Re: DIP 1003: remove `body` as a keyword

2016-12-10 Thread Basile B. via Digitalmars-d-announce

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.
In D there would be the "#" token that's not really used, 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'


Re: DIP 1003: remove `body` as a keyword

2016-12-10 Thread Basile B. via Digitalmars-d-announce

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.
In D there would be the "#" token that's not really used, 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 also a valid identifier character, while "#" is not. 
And the best is that # role is already for special token 
sequences !

- # = token for special token sequence
- 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).


Re: DIP 1003: remove `body` as a keyword

2016-12-10 Thread Rory McGuire via Digitalmars-d-announce
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.
>> In D there would be the "#" token that's not really used, 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
> also a valid identifier character, while "#" is not. And the best is that #
> role is already for special token sequences !
> - # = token for special token sequence
> - 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!


Re: DIP 1003: remove `body` as a keyword

2016-12-11 Thread Basile B. via Digitalmars-d-announce

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.
In D there would be the "#" token that's not really used, 
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
also a valid identifier character, while "#" is not. And the 
best is that #

role is already for special token sequences !
- # = token for special token sequence
- 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.


Re: DIP 1003: remove `body` as a keyword

2016-12-11 Thread Patrick Schluter via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-12-11 Thread Meta via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2016-12-13 Thread Mark via Digitalmars-d-announce
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).


Re: DIP 1003: remove `body` as a keyword

2016-12-15 Thread Basile B. via Digitalmars-d-announce

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




Re: DIP 1003: remove `body` as a keyword

2016-12-15 Thread Namespace via Digitalmars-d-announce

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


Switch from # to @ and even the guys here are satisfied: 
http://forum.dlang.org/thread/fiwfcsqmjsndcjixi...@forum.dlang.org


Two birds - one stone (;


Re: DIP 1003: remove `body` as a keyword

2016-12-15 Thread Basile B. via Digitalmars-d-announce

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


Switch from # to @ and even the guys here are satisfied: 
http://forum.dlang.org/thread/fiwfcsqmjsndcjixi...@forum.dlang.org


Irony I suppose ?


Two birds - one stone (;


Exactly...If # is used to make function attributes (like in point 
4 of 
http://forum.dlang.org/post/lllbfrmrhsjafijlo...@forum.dlang.org) 
then #const like in PR 6324 doesn't work...anyway one of the idea 
is more concrete than the other. ;)


Re: DIP 1003: remove `body` as a keyword

2016-12-15 Thread Meta via Digitalmars-d-announce

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. 
If you have to preface the symbol with # then you might as well 
just use a trailing underscore, like "body_".


Re: DIP 1003: remove `body` as a keyword

2016-12-15 Thread Basile B. via Digitalmars-d-announce

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 
solution. If you have to preface the symbol with # then you 
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).


- 2: the underscore is a valid identifier char, # is not so you 
cannot distinguish a keyword suffixed with an underscore because 
it might be intentional, i.e part of the identifier.





Re: DIP 1003: remove `body` as a keyword

2016-12-30 Thread Arun Chandrasekaran via Digitalmars-d-announce

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.


Re: DIP 1003: remove `body` as a keyword

2017-01-02 Thread Dicebot via Digitalmars-d-announce
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.


DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-02 Thread Mike Parker via Digitalmars-d-announce
Congratulations are in order for Jared Hanson. Walter and Andrei 
have approved his proposal to remove body as a keyword. I've 
added a summary of their decision to the end of the DIP for 
anyone who cares to read it. In short:


* body temporarily becomes a contextual keyword and is deprecated
* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md




Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-02 Thread Jack Stouffer via Digitalmars-d-announce

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Congratulations.

I recommend a longer deprecation cycle than usual for this, as 
this will break many legacy libraries that don't get maintained 
often. A period of two years sounds about right.


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-02 Thread MysticZach via Digitalmars-d-announce

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and 
Andrei have approved his proposal to remove body as a keyword. 
I've added a summary of their decision to the end of the DIP 
for anyone who cares to read it. In short:


* body temporarily becomes a contextual keyword and is 
deprecated

* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Yes, congratulations are in order. Although those of us who were 
questioning the need for any keyword at all in `body`s place may 
be a little disappointed that it has merely been replaced with 
`do`, I think no one can doubt the main thrust of the DIP, which 
is that `body` is an incredibly useful identifier, and that 
having it newly available makes D a better language.


Also, I've been following the forums for several years now, and 
this is the first DIP that I know of that was not written by the 
language authors, and yet was still accepted into the language. 
Correct me if I'm wrong, but that seems like a real landmark!


Also Mike Parker seems to be doing a very good job in his 
appointed position as DIP manager.




Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-02 Thread Jonathan M Davis via Digitalmars-d-announce
On Saturday, June 03, 2017 02:00:13 Jack Stouffer via Digitalmars-d-announce 
wrote:
> I recommend a longer deprecation cycle than usual for this, as
> this will break many legacy libraries that don't get maintained
> often. A period of two years sounds about right.

For Phobos, that _is_ the normal length of the deprecation cycle. For the
language itself, I don't think that it's anywhere near as consistent, but
I've gotten the impression that deprecations in the language usually stick
around for quite awhile, but I haven't exactly tracked it closely, so I
don't know.

- Jonathan M Davis



Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-02 Thread H. S. Teoh via Digitalmars-d-announce
On Sat, Jun 03, 2017 at 04:56:40AM +, MysticZach via Digitalmars-d-announce 
wrote:
[...]
> Yes, congratulations are in order. Although those of us who were
> questioning the need for any keyword at all in `body`s place may be a
> little disappointed that it has merely been replaced with `do`, I
> think no one can doubt the main thrust of the DIP, which is that
> `body` is an incredibly useful identifier, and that having it newly
> available makes D a better language.
[...]

Yes, count me somewhat disappointed at merely changing `body` to `do`.
But at least it's better than nothing, and frees as `body` as an
identifier instead of a keyword that's only ever used in a single
context. And it's marginally shorter to type. :-D


T

-- 
This sentence is false.


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Walter Bright via Digitalmars-d-announce

On 6/2/2017 9:56 PM, MysticZach wrote:
Also Mike Parker seems to be doing a very good job in his appointed position as 
DIP manager.


Yes, I am very happy with Mike's contributions on this, as well as on his blog 
work. We are very fortunate to have Mike with us.




Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread via Digitalmars-d-announce

On Saturday, 3 June 2017 at 04:56:40 UTC, MysticZach wrote:

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and 
Andrei have approved his proposal to remove body as a keyword. 
I've added a summary of their decision to the end of the DIP 
for anyone who cares to read it. In short:


* body temporarily becomes a contextual keyword and is 
deprecated

* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Yes, congratulations are in order. Although those of us who 
were questioning the need for any keyword at all in `body`s 
place may be a little disappointed that it has merely been 
replaced with `do`, I think no one can doubt the main thrust of 
the DIP, which is that `body` is an incredibly useful 
identifier, and that having it newly available makes D a better 
language.


Personally, making contracts less verbose and more powerful is 
much higher on my list (I don't remember ever needing to use 
'body' as an identifier, but I see why is it important for many 
domains), so I'm also disappointed that we replaced one keyword 
with another. At least 'body' will be a contextual keyword, so it 
won't cause a massive breakage.


Also, I've been following the forums for several years now, and 
this is the first DIP that I know of that was not written by 
the language authors, and yet was still accepted into the 
language. Correct me if I'm wrong, but that seems like a real 
landmark!


Yes, it's the first approved DIP after DIP1000, but there are 
quite a few approved DIPs not coming Walter and Andrei before 
that: https://wiki.dlang.org/DIPs - DIP2, DIP3, DIP6, DIP9 (it 
seems it got traction, even though it doesn't say approved) 
DIP12, DIP18 (it looks like it was the first @nogc proposal) 
DIP20, DIP37, DIP42, DIP43 (it's partially implemented), and so 
on.
Actually most language enhancements happened without going 
through the DIP process. These are that went through bugzilla: 
https://issues.dlang.org/buglist.cgi?bug_severity=enhancement&bug_status=RESOLVED&component=dmd&list_id=215170&order=bug_id&product=D&query_based_on=&query_format=advanced&resolution=FIXED&version=D2 and many other exist only as pull requests on GitHub - a very incomplete list: https://github.com/dlang/dmd/pulls?utf8=✓&q=is%3Apr%20is%3Aclosed%20enhancement. If you look carefully at the history in bugzilla and github, even though probably most of the enhancements were little, you'll see there many huge changes to the language that should have gone through the DIP process, but have not.


Also Mike Parker seems to be doing a very good job in his 
appointed position as DIP manager.


Agreed, I'm optimistic about the DIP process under his lead.



Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Jonathan M Davis via Digitalmars-d-announce
On Friday, June 02, 2017 23:44:21 H. S. Teoh via Digitalmars-d-announce 
wrote:
> On Sat, Jun 03, 2017 at 04:56:40AM +, MysticZach via
> Digitalmars-d-announce wrote: [...]
>
> > Yes, congratulations are in order. Although those of us who were
> > questioning the need for any keyword at all in `body`s place may be a
> > little disappointed that it has merely been replaced with `do`, I
> > think no one can doubt the main thrust of the DIP, which is that
> > `body` is an incredibly useful identifier, and that having it newly
> > available makes D a better language.
>
> [...]
>
> Yes, count me somewhat disappointed at merely changing `body` to `do`.
> But at least it's better than nothing, and frees as `body` as an
> identifier instead of a keyword that's only ever used in a single
> context. And it's marginally shorter to type. :-D

I cared far more about getting rid of the need for a keyword there than
freeing up body, so I'm not sure that I care much about this change
(particularly since I rarely deal with cases where I'd use body as a
variable name), but it's still good that body was freed up.

- Jonathan M Davis



Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread ketmar via Digitalmars-d-announce

Petar Kirov [ZombineDev] wrote:

Personally, making contracts less verbose and more powerful is much 
higher on my list (I don't remember ever needing to use 'body' as an 
identifier, but I see why is it important for many domains)


yeah. i'm really tired to use `flesh` instead of it. and i have bodies 
literally everywhere: active, sleeping, dead, broken... several of my game 
engines has more-or-less physics-based simulations, so i need `body`! ;-)


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 6/2/17 10:17 AM, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and Andrei have 
approved his proposal to remove body as a keyword. I've added a summary 
of their decision to the end of the DIP for anyone who cares to read it. 
In short:


* body temporarily becomes a contextual keyword and is deprecated
* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Congrats to all who worked on this. Next step is to revise the DIP that 
puts the approved option to the fore and mentions the others only as 
other options that have been analyzed. This is because we have an 
"Approved" status but not "Approved Option X". Thanks! -- Andrei


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-06-02 16:17, Mike Parker wrote:

Congratulations are in order for Jared Hanson. Walter and Andrei have
approved his proposal to remove body as a keyword. I've added a summary
of their decision to the end of the DIP for anyone who cares to read it.
In short:

* body temporarily becomes a contextual keyword and is deprecated
* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


That's great.

BTW, didn't we use to vote on the DIPs, or was that only for new Phobos 
modules?


--
/Jacob Carlborg


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Mike Parker via Digitalmars-d-announce

On Saturday, 3 June 2017 at 07:01:48 UTC, Walter Bright wrote:

On 6/2/2017 9:56 PM, MysticZach wrote:
Also Mike Parker seems to be doing a very good job in his 
appointed position as DIP manager.


Yes, I am very happy with Mike's contributions on this, as well 
as on his blog work. We are very fortunate to have Mike with us.


Thanks!


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 06/03/2017 11:08 AM, Andrei Alexandrescu wrote:

On 6/2/17 10:17 AM, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and Andrei have 
approved his proposal to remove body as a keyword. I've added a 
summary of their decision to the end of the DIP for anyone who cares 
to read it. In short:


* body temporarily becomes a contextual keyword and is deprecated
* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Congrats to all who worked on this. Next step is to revise the DIP that 
puts the approved option to the fore and mentions the others only as 
other options that have been analyzed. This is because we have an 
"Approved" status but not "Approved Option X". Thanks! -- Andrei


Sorry, was looking at a stale copy. I think the DIP is fine as is. The 
previously discussed options are available as earlier revisions of the 
DIP. -- Andrei


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Walter Bright via Digitalmars-d-announce

On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote:
Personally, making contracts less verbose and more powerful is much higher on my 
list 
We did discuss bouncing the DIP back with a request to revamp it as a complete 
overhaul of the contract syntax, but decided that this DIP was about resolving a 
simple and immediate problem, and it shouldn't be held up on that basis.


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Jonathan M Davis via Digitalmars-d-announce
On Saturday, June 03, 2017 17:16:52 Jacob Carlborg via Digitalmars-d-
announce wrote:
> On 2017-06-02 16:17, Mike Parker wrote:
> > Congratulations are in order for Jared Hanson. Walter and Andrei have
> > approved his proposal to remove body as a keyword. I've added a summary
> > of their decision to the end of the DIP for anyone who cares to read it.
> > In short:
> >
> > * body temporarily becomes a contextual keyword and is deprecated
> > * do is immediately allowed in its place
> > * body is removed and do replaces it fully
> >
> > Congratulations, Jared!
> >
> > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
>
> That's great.
>
> BTW, didn't we use to vote on the DIPs, or was that only for new Phobos
> modules?

Only new Phobos modules. DIPs have been discussed quite a bit in the
newsgroup, but their decision process has never been democratic. It's always
been a matter of talking Walter into it, which has usually led to stuff
never going anywhere when we haven't had a process for it with someone
organizing it. Previously, I think that most DIPs that got implemented were
something that Walter was personally interested in, or you managed to
convince him in person. What Dicebot and Mike have done with DIPs has
changed things drastically, but it's still completely up to Walter and
Andrei.

- Jonathan M Davis



Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Ali Çehreli via Digitalmars-d-announce

On 06/02/2017 11:44 PM, H. S. Teoh via Digitalmars-d-announce wrote:

> Yes, count me somewhat disappointed at merely changing `body` to `do`.

If that's the only change, then we have a serious issue with the text of 
this DIP. I think the DIP must be corrected with the following change. 
Please review and then change the DIP accordingly:


from: "Add do as an optional keyword in the place of body."

  to: "Add do as an alternative keyword in place of body."

(Unimportantly, I removed a "the" as well.)

Ali



Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Mike Parker via Digitalmars-d-announce

On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote:

On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote:
Personally, making contracts less verbose and more powerful is 
much higher on my list
We did discuss bouncing the DIP back with a request to revamp 
it as a complete overhaul of the contract syntax, but decided 
that this DIP was about resolving a simple and immediate 
problem, and it shouldn't be held up on that basis.


There's currently a proposal in the PR queue to enhance the 
contract syntax.


https://github.com/dlang/DIPs/pull/66


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Mike Parker via Digitalmars-d-announce

On Saturday, 3 June 2017 at 23:43:10 UTC, Ali Çehreli wrote:



If that's the only change, then we have a serious issue with 
the text of this DIP. I think the DIP must be corrected with 
the following change. Please review and then change the DIP 
accordingly:


from: "Add do as an optional keyword in the place of body."

  to: "Add do as an alternative keyword in place of body."

(Unimportantly, I removed a "the" as well.)

Ali


I think the two words are fairly close in meaning in this 
context. Changed it anyway (and caught a typo, too). Thanks!


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Walter Bright via Digitalmars-d-announce

On 6/2/2017 7:17 AM, Mike Parker wrote:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


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


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Walter Bright via Digitalmars-d-announce

On 6/3/2017 5:20 PM, Mike Parker wrote:

On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote:

On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote:
Personally, making contracts less verbose and more powerful is much higher on 
my list
We did discuss bouncing the DIP back with a request to revamp it as a complete 
overhaul of the contract syntax, but decided that this DIP was about resolving 
a simple and immediate problem, and it shouldn't be held up on that basis.


There's currently a proposal in the PR queue to enhance the contract syntax.

https://github.com/dlang/DIPs/pull/66


I know. That's as it should be!


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Jack Stouffer via Digitalmars-d-announce

On Saturday, 3 June 2017 at 06:09:21 UTC, Jonathan M Davis wrote:
On Saturday, June 03, 2017 02:00:13 Jack Stouffer via 
Digitalmars-d-announce wrote:
I recommend a longer deprecation cycle than usual for this, as 
this will break many legacy libraries that don't get 
maintained often. A period of two years sounds about right.


For Phobos, that _is_ the normal length of the deprecation 
cycle. For the language itself, I don't think that it's 
anywhere near as consistent, but I've gotten the impression 
that deprecations in the language usually stick around for 
quite awhile, but I haven't exactly tracked it closely, so I 
don't know.


- Jonathan M Davis


All of the recent Phobos deprecations have been a year. 18 months 
at most.


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-04 Thread Jonathan M Davis via Digitalmars-d-announce
On Sunday, June 04, 2017 05:56:15 Jack Stouffer via Digitalmars-d-announce 
wrote:
> On Saturday, 3 June 2017 at 06:09:21 UTC, Jonathan M Davis wrote:
> > On Saturday, June 03, 2017 02:00:13 Jack Stouffer via
> >
> > Digitalmars-d-announce wrote:
> >> I recommend a longer deprecation cycle than usual for this, as
> >> this will break many legacy libraries that don't get
> >> maintained often. A period of two years sounds about right.
> >
> > For Phobos, that _is_ the normal length of the deprecation
> > cycle. For the language itself, I don't think that it's
> > anywhere near as consistent, but I've gotten the impression
> > that deprecations in the language usually stick around for
> > quite awhile, but I haven't exactly tracked it closely, so I
> > don't know.
> >
> > - Jonathan M Davis
>
> All of the recent Phobos deprecations have been a year. 18 months
> at most.

If you think that, I think that you misunderstand how the Phobos deprecation
process works. When a symbol is deprecated, it's marked in the documentation
with the year-month that it will be removed from the documentation (usually
about one year from the point that it's deprecated). Once that year has
passed, the documentation is removed from Phobos, and instead, it's marked
with a non-ddoc comment stating that the symbol is explicitly undocumented
and that it will be removed at year-month where that's usually a year from
when the symbol is removed from the documentation. Once that second date
arrives, the symbol is completely removed. So, the whole deprecation cycle
is approximately two years, and if anything, it sometimes takes a bit
longer, because I'm sometimes slow to move the symbol along to the next
stage.

I suspect that what's confused you is that when the symbol is deprecated, it
states in the documentation that the symbol will be removed at year-month
and does not say anything about the fact that that removal date is when it
will be removed from the documentation, not when it will be fully removed
from the library.

- Jonathan M Davis



Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-04 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-06-04 01:10, Jonathan M Davis via Digitalmars-d-announce wrote:


Only new Phobos modules. DIPs have been discussed quite a bit in the
newsgroup, but their decision process has never been democratic. It's always
been a matter of talking Walter into it, which has usually led to stuff
never going anywhere when we haven't had a process for it with someone
organizing it. Previously, I think that most DIPs that got implemented were
something that Walter was personally interested in, or you managed to
convince him in person. What Dicebot and Mike have done with DIPs has
changed things drastically, but it's still completely up to Walter and
Andrei.


Right.

--
/Jacob Carlborg


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-04 Thread MysticZach via Digitalmars-d-announce

On Sunday, 4 June 2017 at 03:01:41 UTC, Walter Bright wrote:

On 6/3/2017 5:20 PM, Mike Parker wrote:
There's currently a proposal in the PR queue to enhance the 
contract syntax.


https://github.com/dlang/DIPs/pull/66


I know. That's as it should be!


Well that's encouraging! Thanks!


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-05 Thread via Digitalmars-d-announce

On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote:

On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote:
Personally, making contracts less verbose and more powerful is 
much higher on my list
We did discuss bouncing the DIP back with a request to revamp 
it as a complete overhaul of the contract syntax, but decided 
that this DIP was about resolving a simple and immediate 
problem, and it shouldn't be held up on that basis.


Yes, keeping scope of DIP1003 was the right call. In order to for 
the process to be effective, we need to have good turnaround time.
That said, I'm glad to hear that the idea of an overhaul the 
contract syntax is on your radar. Related to that, is the need to 
formally specify what exactly is the compiler allowed to assume 
via asserts. Currently the answer is offensive​ programming [0] 
which doesn't play well with domains that require defensive​ 
programming. But that's a topic for another day and another DIP.


[0]: 
https://en.wikipedia.org/wiki/Defensive_programming#Offensive_programming


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-05 Thread Olivier FAURE via Digitalmars-d-announce

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


The "See the previous version" link at the end of the document is 
currently broken and leads to a 404.


Thank you for your efforts and congratulations to Jared Hanson!


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-07 Thread Meta via Digitalmars-d-announce

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and 
Andrei have approved his proposal to remove body as a keyword. 
I've added a summary of their decision to the end of the DIP 
for anyone who cares to read it. In short:


* body temporarily becomes a contextual keyword and is 
deprecated

* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Well, guess I'm a bit late to the party but I just wanted to echo 
the sentiment that Mike has done a great job stepping up to 
oversee the DIP process. All I had to do was write it, and he did 
the rest. I'm very pleased with how smoothly things went and how 
easy Mike made the whole process. Thanks Mike!