May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Petar Kirov [ZombineDev] | On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote:
> On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
> > The first stage of the formal review for DIP 1003 [1], "Remove body as a Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input.
> >
> > At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate.
> >
> > [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba 555/DIPs/DIP1003.md
> >
> > [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>
> I vote for option 4 - a combination of 1 and 3:
> * Make body a contextual keyword
> * Allow omitting it
> * No need for deprecation
>
> I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context:
>
> // 1:
> int C;
> C++;
>
> // 2:
> extern (C++) void foo();
Except that C++ is not a keyword anymore than linux is a keyword in
version(linux)
It's an identifier (albeit one that doesn't quite follow the normal naming scheme for identifiers). D does not have contextual keywords, and Walter is completely against adding them, so I'd expect that any proposal that required them would be DOA. And not having them definitely simplifies lexing and parsing D code, so it's quite understandable that Walter is against them.
- Jonathan M Davis
|
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | On Fri, 12 May 2017 16:17:03 +0000, Mike Parker wrote: > The first stage of the formal review for DIP 1003 [1], "Remove body as a Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input. > > At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate. > > [1] > https://github.com/dlang/DIPs/blob/ fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md > > [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org For option one, there would also need to be a discussion of whether to allow us to use in and out as identifiers for consistency (I used them more often than body in my pre-D programming); I would say no, but could argue either way. It's a slippery slope. I think option three is ugly, but I could live with it. I thought ()() was ugly for templates too, but now they're just normal. How about: void func() in { assert(true); } out { assert(true); } nowWeFinallyGetToTheFunctionBodyProvidedThereWereNoProblems { // I don't think we'll have to worry about name clashes... } |
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Saturday, 13 May 2017 at 10:46:51 UTC, Jonathan M Davis wrote: > On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote: >> On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote: >> > The first stage of the formal review for DIP 1003 [1], "Remove body as a Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input. >> > >> > At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate. >> > >> > [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba 555/DIPs/DIP1003.md >> > >> > [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org >> >> I vote for option 4 - a combination of 1 and 3: >> * Make body a contextual keyword >> * Allow omitting it >> * No need for deprecation >> >> I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context: >> >> // 1: >> int C; >> C++; >> >> // 2: >> extern (C++) void foo(); > > Except that C++ is not a keyword anymore than linux is a keyword in > > version(linux) > > It's an identifier (albeit one that doesn't quite follow the normal naming scheme for identifiers). No, they're not the same. 'something' in 'version (something)' or 'debug (something)' can be either: 1) an integer 2) 'assert' or 'unittest' keyword 3) an identifier. 'debug' and 'version' identifiers live in their own namespaces which is why they don't conflict with other identifiers in the program. 'linux' in the context of 'version (linux)' is 3) - a predefined version identifier, and like all other identifiers it has to obey by a certain set of rules [1]. E.g. you can't have 'version (C++-interop)'. Contextual keywords [2] like 'C++', 'Objective-C' or 'exit' on the other hand are not identifiers and that's why don't need to follow [1]. The fact that the spec refuses to call them keywords [3] and they are parsed as identifiers [4],[5] (but only the 'C' and 'Objective' parts) in dmd is an artifact of an implementation detail. In essence, they behave exactly as contextual keywords in C# [6]. But just for fun, let's say I play you're game. Then why not make 'body' an identifier living in it's own namespace, just like 'failure' and 'exit'? :P > ... and Walter is completely against adding them, so I'd expect that any proposal that required them would be DOA. And not having them definitely simplifies lexing and parsing D code, so it's quite understandable that Walter is against them. > You're just trying to represent Walter's opinion without adding new information. Adding contextual keywords to a language with context free grammar won't make the language grammar context dependent and that's why I don't buy the argument that this would somehow complicate the process parsing D code. Yes, it may require changes to dmd, but in general it's not a difficult problem to solve, as other language implementation demonstrate quite well. [0]: https://dlang.org/spec/version.html#version [1]: https://dlang.org/spec/lex.html#Identifier [2]: See Timon's post for a more complete list: http://forum.dlang.org/post/of6n2e$2ne2$1@digitalmars.com [3]: http://dlang.org/spec/attribute.html#linkage [4]: https://github.com/dlang/dmd/blob/v2.074.0/src/ddmd/parse.d#L2148 [5]: https://github.com/dlang/dmd/blob/v2.074.0/src/ddmd/parse.d#L5418 [6]: https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/contextual-keywords |
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | On 5/12/2017 9:17 AM, Mike Parker wrote:
> The first stage of the formal review for DIP 1003 [1], "Remove body as a
> Keyword", is now underway.
I'd like to congratulate Jared Hanson for a particularly well-written DIP which sets a high standard for how things ought to be done. Well done!
|
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 13 May 2017 at 13:16:40 UTC, Walter Bright wrote:
> On 5/12/2017 9:17 AM, Mike Parker wrote:
>> The first stage of the formal review for DIP 1003 [1], "Remove body as a
>> Keyword", is now underway.
>
> I'd like to congratulate Jared Hanson for a particularly well-written DIP which sets a high standard for how things ought to be done. Well done!
Thank you. Actually, I'd like to ask, are you still as strongly in opposition to making `body` a contextual keyword as you were previously? To me that seems to be the easiest solution, although I am happy going with any of the three proposed solutions.
|
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote: > On 12.05.2017 18:17, Mike Parker wrote: >> The first stage of the formal review for DIP 1003 [1], "Remove body as a >> Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM >> GMT on May 27), the community has the opportunity to provide last-minute >> feedback. If you missed the preliminary review [2], this is your chance >> to provide input. >> >> At the end of the feedback period, I will submit the DIP to Walter and >> Andrei for their final decision. Thanks in advance to those of you who >> participate. >> >> [1] >> https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md >> >> >> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org > > Option 1 is good: There is nothing wrong with the current syntax. [1] > > Option 2 is bad: It's the function body, not the function. > > Option 3 is ugly: There is no precedent for '...{}{}' belonging to the same declaration or statement. Hmm, I guess it depends on how you format your code. I noticed that you tend to avoid whitespace when formatting your own code (e.g. [0]) so if '{}{}' was allowed (in addition to '()()') your code would look even more cryptic (at least to me) :P The Phobos style guide, which also mostly matches my personal preference is to write code like this: T sqrt(T)(T n) if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt)) in { assert(n >= 0); } out (result) { assert(result * result == n); } body { //Implementation } If the block is short I sometimes write it like so: T sqrt(T)(T n) if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt)) in { assert(n >= 0); } out (result) { assert(result * result == n); } body { //Implementation } With removal of 'body', the code would look like so: T sqrt(T)(T n) if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt)) in { assert(n >= 0); } out (result) { assert(result * result == n); } { //Implementation } Which I actually think looks good. A small improvement, in addition to omitting 'body' would be to allow omitting the braces if the 'in' or 'out' blocks contain only a single statement (similar to 'if', 'foreach', etc.) and to add a similar syntax sugar alternative for template constraints: T sqrt(T)(T n) if Unqual!T U: isNumeric!U || is(U == BigInt) in n >= 0 out (result) result * result == n { //Implementation } [0]: https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/semantic.d#L845 https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/parser.d#L122 https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/semantic.d#L131 |
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Petar Kirov [ZombineDev] | On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
> On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
>> On 12.05.2017 18:17, Mike Parker wrote:
>>> The first stage of the formal review for DIP 1003 [1], "Remove body as a
>>> Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
>>> GMT on May 27), the community has the opportunity to provide last-minute
>>> feedback. If you missed the preliminary review [2], this is your chance
>>> to provide input.
>>>
>>> At the end of the feedback period, I will submit the DIP to Walter and
>>> Andrei for their final decision. Thanks in advance to those of you who
>>> participate.
>>>
>>> [1]
>>> https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>>>
>>>
>>>
>>> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>>
>> Option 1 is good: There is nothing wrong with the current syntax. [1]
>>
>> Option 2 is bad: It's the function body, not the function.
>>
>> Option 3 is ugly: There is no precedent for '...{}{}' belonging to the
>> same declaration or statement.
>
> Hmm, I guess it depends on how you format your code.
No, it does not. This was a point about the grammar.
How would you feel about:
if(condition){ then(); }
{ otherwise(); }
|
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
> On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
>> On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
>>> On 12.05.2017 18:17, Mike Parker wrote:
>>>> The first stage of the formal review for DIP 1003 [1], "Remove body as a
>>>> Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
>>>> GMT on May 27), the community has the opportunity to provide last-minute
>>>> feedback. If you missed the preliminary review [2], this is your chance
>>>> to provide input.
>>>>
>>>> At the end of the feedback period, I will submit the DIP to Walter and
>>>> Andrei for their final decision. Thanks in advance to those of you who
>>>> participate.
>>>>
>>>> [1]
>>>> https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>>>>
>>>>
>>>>
>>>> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>>>
>>> Option 1 is good: There is nothing wrong with the current syntax. [1]
>>>
>>> Option 2 is bad: It's the function body, not the function.
>>>
>>> Option 3 is ugly: There is no precedent for '...{}{}' belonging to the
>>> same declaration or statement.
>>
>> Hmm, I guess it depends on how you format your code.
>
> No, it does not. This was a point about the grammar.
>
> How would you feel about:
>
> if(condition){ then(); }
> { otherwise(); }
It isn't the same.
1) It is ambiguous: { otherwise(); } can be a statement in a block or an else condition. But it wasn't the real point.
2) Nested ifs are used much more often than nested functions, and the code with a lot of nested ifs would look unreadable without else. It isn't the case for the functions. I suppose that contracts a mostly used on outer functions and it would look pretty clear.
|
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eugene Wissner | On 13.05.2017 20:26, Eugene Wissner wrote:
> On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
>> On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
>>> On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
>>>> On 12.05.2017 18:17, Mike Parker wrote:
>>>>> The first stage of the formal review for DIP 1003 [1], "Remove body
>>>>> as a
>>>>> Keyword", is now underway. From now until 11:59 PM ET on May 26
>>>>> (3:59 AM
>>>>> GMT on May 27), the community has the opportunity to provide
>>>>> last-minute
>>>>> feedback. If you missed the preliminary review [2], this is your
>>>>> chance
>>>>> to provide input.
>>>>>
>>>>> At the end of the feedback period, I will submit the DIP to Walter and
>>>>> Andrei for their final decision. Thanks in advance to those of you who
>>>>> participate.
>>>>>
>>>>> [1]
>>>>> https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>>>>
>>>> Option 1 is good: There is nothing wrong with the current syntax. [1]
>>>>
>>>> Option 2 is bad: It's the function body, not the function.
>>>>
>>>> Option 3 is ugly: There is no precedent for '...{}{}' belonging to the
>>>> same declaration or statement.
>>>
>>> Hmm, I guess it depends on how you format your code.
>>
>> No, it does not. This was a point about the grammar.
>>
>> How would you feel about:
>>
>> if(condition){ then(); }
>> { otherwise(); }
>
> It isn't the same.
> ...
It does not need to be "the same", and I didn't claim it was "the same".
I'm just trying to illustrate why it does not fit into the D grammar. There is no technical point here. "Ugly" does not mean "unreadable" or "broken". It just means it is bad taste. YMMV.
|
May 13, 2017 Re: DIP 1003 Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
> On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
>> On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
>>> On 12.05.2017 18:17, Mike Parker wrote:
>>>> The first stage of the formal review for DIP 1003 [1], "Remove body as a
>>>> Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
>>>> GMT on May 27), the community has the opportunity to provide last-minute
>>>> feedback. If you missed the preliminary review [2], this is your chance
>>>> to provide input.
>>>>
>>>> At the end of the feedback period, I will submit the DIP to Walter and
>>>> Andrei for their final decision. Thanks in advance to those of you who
>>>> participate.
>>>>
>>>> [1]
>>>> https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>>>>
>>>>
>>>>
>>>> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>>>
>>> Option 1 is good: There is nothing wrong with the current syntax. [1]
>>>
>>> Option 2 is bad: It's the function body, not the function.
>>>
>>> Option 3 is ugly: There is no precedent for '...{}{}' belonging to the
>>> same declaration or statement.
>>
>> Hmm, I guess it depends on how you format your code.
>
> No, it does not. This was a point about the grammar.
>
> How would you feel about:
>
> if(condition){ then(); }
> { otherwise(); }
I don't see any problem, in fact this is valid code even today - both in C++ and D.
And my case still stands - if you were to format the code like this:
if (condition)
{
then();
}
{
otherwise();
}
then the intent would be more obvious. At least in C++ using a plain scope { }
is common idiom used to explicitly limit the lifetime of RAII objects declared
within it.
|
Copyright © 1999-2021 by the D Language Foundation