May 18, 2017
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
> http://forum.dlang.org/post/kybywnscisxpebezwyvk@forum.dlang.org ) represents yet another distinct option. i.e. continue to allow `body`, but make it optional, that is, you can simply omit it if you want, while also allowing it as an identifier.

For the record, this was first suggested by H. S. Teoh:
http://forum.dlang.org/post/mailman.2204.1494612727.31550.digitalmars-d@puremagic.com
May 18, 2017
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
> On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
>> On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
>>> I'll add this option to the DIP.
>>
>> https://github.com/dlang/DIPs/pull/65
>
> I think ( http://forum.dlang.org/post/kybywnscisxpebezwyvk@forum.dlang.org ) represents yet another distinct option. i.e. continue to allow `body`, but make it optional, that is, you can simply omit it if you want, while also allowing it as an identifier.

This is pretty much the same as option 2. The short-term contextual part is covered by Walter's suggestion.
May 18, 2017
On Thursday, 18 May 2017 at 12:56:31 UTC, Meta wrote:
> On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
>> On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
>>> On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
>>>> I'll add this option to the DIP.
>>>
>>> https://github.com/dlang/DIPs/pull/65
>>
>> I think ( http://forum.dlang.org/post/kybywnscisxpebezwyvk@forum.dlang.org ) represents yet another distinct option. i.e. continue to allow `body`, but make it optional, that is, you can simply omit it if you want, while also allowing it as an identifier.
>
> This is pretty much the same as option 2. The short-term contextual part is covered by Walter's suggestion.

No it's not. What MysticZach suggests, and what I suggested even earlier [0] is to make 'body' contextual and optional which is very different than replacing it with another keyword. The main difference is that it would make code that uses contracts cleaner and there would be no breakage. In contrast, deprecating 'body' is a breaking change.

IMO, option 2 and variations of it are *the worst* way forward.

[0]: http://forum.dlang.org/post/pmldhzgcpuoydllfrbei@forum.dlang.org
May 18, 2017
On Thursday, 18 May 2017 at 13:06:38 UTC, Petar Kirov [ZombineDev] wrote:
> On Thursday, 18 May 2017 at 12:56:31 UTC, Meta wrote:
>> This is pretty much the same as option 2. The short-term contextual part is covered by Walter's suggestion.
>
> No it's not. What MysticZach suggests, and what I suggested even earlier [0] is to make 'body' contextual and optional which is very different than replacing it with another keyword. The main difference is that it would make code that uses contracts cleaner and there would be no breakage. In contrast, deprecating 'body' is a breaking change.
>
> IMO, option 2 and variations of it are *the worst* way forward.
>
> [0]: http://forum.dlang.org/post/pmldhzgcpuoydllfrbei@forum.dlang.org

Yes. Our proposal is actually a variation on option 3. Added to the current DIP, it would read: "Option 6: allow omitting `body`, and also allow it as an identifier"

The two known downsides to this option so far are:

1. Different code will continue include the keyword version of `body` or not based on arbitrary programmer preferences.

2. Syntax highlighters that choose to highlight the word `body` will have to be modified to detect its different uses.

Note that in the case of 1., strong preferences have been stated here for both styles, thus increasing the feeling that it's okay to allow both. Also note that the opposition to any inclusion of contextual keywords on principle is largely countered by the fact that there is no danger of semantic ambiguity between the two uses of `body` here.

May 23, 2017
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
> I think there are several issues at hand, and they need to be dealt with individually:
>
> 1. `body` is a very useful identifier. It would be nice to have it available.
>
> 2. Contract syntax is too verbose.
>
> 3. a. Some people think code looks better with a keyword, e.g. `body`, `do`, etc. distinguishing the function from the contracts.
>
> 3. b. Other people think that such a keyword is unnecessarily redundant and does not justify its own existence.
>
> I think the thread will be more productive if the posters commit to answering just one of these issues, and reserve other issues for other threads. As the DIP in question is directly meant to address issue #1, it makes sense to try to solve that problem and only that problem here.

I made a related DIP discussing issue 2, contract syntax is too verbose. The thread for discussing that one is here:

http://forum.dlang.org/post/tuzdqqpcoguatepgxupq@forum.dlang.org
May 25, 2017
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
> The first stage of the formal review for DIP 1003 [1], "Remove body as a Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input.
>
> At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate.
>
> [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>
> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org

I believe the relevant discussion for this DIP can be simplified to just these two questions:

1. Should `body` be allowed as an identifier?

2. Should the keyword `body` remain as it is?

But it's been demonstrated that these two issues do _not_ need to be decided together. Because there is no known possibility of semantic confusion between the two potential uses of `body`, the arguments against allowing `body` as a contextual keyword are reduced to two minor points:

A. syntax highlighters will get confused
B. some programmers consider contextual keywords to be "bad karma"

It's possible to answer Question 1 based on these points alone.

Only if one decides that the answer to Question 2 is "no" — i.e. that `body` as a keyword needs to change — does it open up the discussion on the various options for changing it. But that could technically be the subject of a different DIP.
May 25, 2017
On Thursday, 25 May 2017 at 11:49:47 UTC, MysticZach wrote:
> ...there is no known possibility of semantic confusion between the two potential uses of `body`,

I spoke too soon. I found a place where such semantic ambiguity is possible. It can only occur in interface declarations, and will not exist in any currently compilable D code, as it requires `body` to be an identifier to be legal in the first place.

Currently, the only place in D where you can declare a function that has a contract, but no body, is in an interface. D syntax, it turns out, does not require a semicolon at the end of such declarations. Referencing https://dlang.org/spec/interface.html#interface-contracts we have:

interface I
{
    int foo(int i)
    in { assert(i); } // <-- no semicolon required

    void bar();
}

Therefore, with `body` as an identifier, you might have this ambiguity:

struct body {}

interface I {
  int foo(int i)
  in { assert(i); }

  body bar();
}

The ambiguity is fixable by modifying the parser to look ahead after `body` for `{`. Since virtual interface functions are not even allowed to have bodies, if it finds `{`, then `body` should be interpreted as a keyword, and an error issued. In all other cases `body` should be interpreted as an identifier.

This is not a hard problem, but it is indeed a semantic ambiguity, so it bears mentioning.
May 26, 2017
On 25.05.2017 20:57, MysticZach wrote:
> On Thursday, 25 May 2017 at 11:49:47 UTC, MysticZach wrote:
>> ...there is no known possibility of semantic confusion between the two potential uses of `body`,
> 
> I spoke too soon. I found a place where such semantic ambiguity is possible. It can only occur in interface declarations, and will not exist in any currently compilable D code, as it requires `body` to be an identifier to be legal in the first place.
> 
> Currently, the only place in D where you can declare a function that has a contract, but no body, is in an interface. D syntax, it turns out, does not require a semicolon at the end of such declarations. Referencing https://dlang.org/spec/interface.html#interface-contracts we have:
> 
> interface I
> {
>      int foo(int i)
>      in { assert(i); } // <-- no semicolon required
> 
>      void bar();
> }
> 
> Therefore, with `body` as an identifier, you might have this ambiguity:
> 
> struct body {}
> 
> interface I {
>    int foo(int i)
>    in { assert(i); }
> 
>    body bar();
> }
> 
> The ambiguity is fixable by modifying the parser to look ahead after `body` for `{`. Since virtual interface functions are not even allowed to have bodies, if it finds `{`, then `body` should be interpreted as a keyword, and an error issued. In all other cases `body` should be interpreted as an identifier.
> 
> This is not a hard problem, but it is indeed a semantic ambiguity, so it bears mentioning.

There is no ambiguity, because only one valid interpretation exists.
May 26, 2017
On Friday, 26 May 2017 at 01:23:59 UTC, Timon Gehr wrote:
> On 25.05.2017 20:57, MysticZach wrote:
>> struct body {}
>> 
>> interface I {
>>    int foo(int i)
>>    in { assert(i); }
>> 
>>    body bar();
>> }
>> 
>> The ambiguity is fixable by modifying the parser to look ahead after `body` for `{`. Since virtual interface functions are not even allowed to have bodies, if it finds `{`, then `body` should be interpreted as a keyword, and an error issued. In all other cases `body` should be interpreted as an identifier.
>> 
>> This is not a hard problem, but it is indeed a semantic ambiguity, so it bears mentioning.
>
> There is no ambiguity, because only one valid interpretation exists.

Well the parser needs to be aware of `body` here both as a keyword and as an identifier, and to use context to determine which one it is. So to me, that counts as a semantic ambiguity, one that is resolved trivially, by a single additional token.

It doesn't seem like it lives up to a more generalized fear of having contextual keywords, unless it's like guy https://www.youtube.com/watch?v=tgj3nZWtOfA
May 27, 2017
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
> The first stage of the formal review for DIP 1003 [1], "Remove body as a Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input.
>
> At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate.
>
> [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>
> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org

The feedback period is complete. Thanks to all who participated. This will now go to Walter and Andrei for final evaluation. I'll report later on their decision.
1 2 3 4 5 6 7 8 9 10
Next ›   Last »