On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:
>
> "int safe = 0; // This code would break if "safe" was added as a keyword"
>

I'm not buying this one. The compiler could issue a warning, something like "Warning: keyword safe will become a keyword in future version, please rename the identifier", then after few months remove it.

Some code will break, sure, but it's a mechanical change that should be possible to apply by some tool. Also, with proper dub package validation, it should be easy to assess how many packages actually break if any. It's one thing to break vibe-d or diamondmvc, it's other thing to break helloworld-d that wasn't updated in seven years.

On Saturday, 22 September 2018 at 19:41:16 UTC, JN wrote:
> Some code will break, sure, but it's a mechanical change that should be possible to apply by some tool.

Who will run this tool? Who's gonna merge the PRs created with this tool?
Compatibility fixes would have been easy in the past in many cases - nevertheless, it needs someone to apply them. Which often did not happen in the past, unfortunately.


> Also, with proper dub package validation, it should be easy to assess how many packages actually break if any.

Now that there's the tester by Neia, one will see whether this works in practice. Time will tell.

On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:
> On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler wrote:
>> On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:
>>> On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan Marler wrote:
>>>> On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:
>>>>> Then D isn't the right choice for you.
>>>>
>>>> I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax.  I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal.
>>>
>>> That inconsistency is an issue for me. I wish there a clear decision to make things consistent.
>>
>> Yeah there's been alot of discussion around it over the years, which is why I put this together about 4 years ago:
>>
>> https://wiki.dlang.org/Language_Designs_Explained#Function_attributes
>>
>> Gosh I've forgotten how long I've been using D.
>
> Interesting article.
>
> "int safe = 0; // This code would break if "safe" was added as a keyword"
>
> My question here: why didn't D use a similar solution as C when dealing with these things? Look at the introduction of the bool datatype in C99. They created the compiler reserved type "_Bool" and put "typedef _Bool bool" in "stdbool.h". The people wanting to use this new feature can include this header, and other can leave it be. No ugly "@" polluting the language on every line where it's used. Wouldn't a similar solution have been possible in D?

That works for types but wouldn't work for keywords. Keywords have special meaning in the lexical stage and you can't extend/change the grammar of the language via an alias or typedef.  You could do something like this with a preprocessor but then you run into all sorts of other problems (i.e. #define safe @safe).

If you come up with other ideas then feel free to share.  No one likes the current state but no one has come up with a good solution yet.

On Saturday, 22 September 2018 at 20:40:14 UTC, Jonathan Marler wrote:
> On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:
>> [...]
>
> That works for types but wouldn't work for keywords. Keywords have special meaning in the lexical stage and you can't extend/change the grammar of the language via an alias or typedef.  You could do something like this with a preprocessor but then you run into all sorts of other problems (i.e. #define safe @safe).
>
> If you come up with other ideas then feel free to share.  No one likes the current state but no one has come up with a good solution yet.

C++ added contextual keywords, like `override` and `final`. If this can be done in C++, surely D is easier to parse?

On Saturday, 22 September 2018 at 20:40:14 UTC, Jonathan Marler wrote:
> On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:
>> On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler wrote:
>>> On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:
>>>> On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan Marler wrote:
>>>>> On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:
>>>>>> Then D isn't the right choice for you.
>>>>>
>>>>> I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax.  I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal.
>>>>
>>>> That inconsistency is an issue for me. I wish there a clear decision to make things consistent.
>>>
>>> Yeah there's been alot of discussion around it over the years, which is why I put this together about 4 years ago:
>>>
>>> https://wiki.dlang.org/Language_Designs_Explained#Function_attributes
>>>
>>> Gosh I've forgotten how long I've been using D.
>>
>> Interesting article.
>>
>> "int safe = 0; // This code would break if "safe" was added as a keyword"
>>
>> My question here: why didn't D use a similar solution as C when dealing with these things? Look at the introduction of the bool datatype in C99. They created the compiler reserved type "_Bool" and put "typedef _Bool bool" in "stdbool.h". The people wanting to use this new feature can include this header, and other can leave it be. No ugly "@" polluting the language on every line where it's used. Wouldn't a similar solution have been possible in D?
>
> That works for types but wouldn't work for keywords. Keywords have special meaning in the lexical stage and you can't extend/change the grammar of the language via an alias or typedef.  You could do something like this with a preprocessor but then you run into all sorts of other problems (i.e. #define safe @safe).
>
> If you come up with other ideas then feel free to share.  No one likes the current state but no one has come up with a good solution yet.

Yes, of course you are right. A typedef for this problem wouldn't be good enough. But there are plenty of other solutions to encapsulate the ugliness in one area instead of spreading it to every codeline. What about a compiler switch like the one in gcc? "-std=c11"? until making the change to default?

There is an excellent speech from Scott Meyers about this. I loved his books about C++, and his recommendations for D are just as good. 41:00 into the video he mentions the legacy crud of C++ and the accidental complexity it contains. He advises D to avoid the need of having "explainers" like him in the future, and to use the small legacy codebase in D to remove/avoid such accidental complexity.

https://www.youtube.com/watch?v=KAWA1DuvCnQ

I don't think enough people listened to him.

On Saturday, 22 September 2018 at 20:53:02 UTC, krzaq wrote:
> C++ added contextual keywords, like `override` and `final`. If this can be done in C++, surely D is easier to parse?

Currently this compiles:

alias safe = int;

@safe foo() { return 1; }
safe bar() { return 2; }

Making "safe" a keyword would cause the second definition to be ambiguous.

(Not that there's much incentive to keep this syntax valid...)

On Saturday, 22 September 2018 at 20:53:02 UTC, krzaq wrote:
> On Saturday, 22 September 2018 at 20:40:14 UTC, Jonathan Marler wrote:
>> On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:
>>> [...]
>>
>> That works for types but wouldn't work for keywords. Keywords have special meaning in the lexical stage and you can't extend/change the grammar of the language via an alias or typedef.  You could do something like this with a preprocessor but then you run into all sorts of other problems (i.e. #define safe @safe).
>>
>> If you come up with other ideas then feel free to share.  No one likes the current state but no one has come up with a good solution yet.
>
> C++ added contextual keywords, like `override` and `final`. If this can be done in C++, surely D is easier to parse?

https://wiki.dlang.org/Language_Designs_Explained#Why_don.27t_we_create_a_special_rule_in_the_syntax_to_handle_non-keyword_function_attributes_without_an_.27.40.27_character.3F

On Saturday, 22 September 2018 at 20:53:02 UTC, krzaq wrote:
> C++ added contextual keywords, like `override` and `final`. If this can be done in C++, surely D is easier to parse?

If D did more stuff like that, it would start to be harder to parse.

On 23/09/2018 2:31 AM, Jonathan Marler wrote:
> On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:
>> Then D isn't the right choice for you.
> 
> I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax.  I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal.

It's much better for the language and for the person looking into a technology to be open to saying that it isn't the right tool for the job after some discussion which has taken place.

I would much rather stop people looking instead of trying to impose changes on us that are not likely to happen in any acceptable time span. Let alone at all. At least then, they can look back and see that we didn't want to waste their or our time trying to compromise on something that wasn't going to happen anyway.

After all, don't we want to make people happy with their decision?

On Saturday, September 22, 2018 7:34:55 PM MDT rikki cattermole via Digitalmars-d wrote:
> On 23/09/2018 2:31 AM, Jonathan Marler wrote:
> > On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:
> >> Then D isn't the right choice for you.
> >
> > I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax.  I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal.
>
> It's much better for the language and for the person looking into a technology to be open to saying that it isn't the right tool for the job after some discussion which has taken place.
>
> I would much rather stop people looking instead of trying to impose changes on us that are not likely to happen in any acceptable time span. Let alone at all. At least then, they can look back and see that we didn't want to waste their or our time trying to compromise on something that wasn't going to happen anyway.
>
> After all, don't we want to make people happy with their decision?

We want to understand where D can and should be improved, but we also need to acknowledge where it shouldn't be changed. Not everyone is going to be happy with it, and we shouldn't try to make it so that everyone is going to be happy with it. For instance, from what I know of Go, I would be _extremely_ unhappy with it, and yet there are folks who absolutely love it. Would I try to convince such folks to come to D? No. If that's the kind of taste that they have in languages, I'd rather that they'd stay away from D and not risk affecting it in a negative way for me. On the other hand, if D fits reasonably well for someone but doesn't quite fit well enough due to some problem with the language, then maybe there's something that we can do to address that, making D work for them, and making it a better language for the rest of us.

Ultimately, it's a question of balance. We want to improve D and make it work for more people, but we also don't want to make it worse for ourselves in the process of trying to make it work better for someone else. Listening to complaints about the language from both those trying it out and those who use it regularly can be important. Ultimately though, I think that it makes a lot more sense to focus on trying to fix the problems that existing users have rather than trying to fix the problems that potential users have. As Walter likes to talk about, when someone tells you why they're not using something, and you solve that problem for them, they always have another reason. And really, while we want D to have a large user base, as users of the language, first and foremost, we want it to work well for ourselves. If we can make the language work really well for what we need, then it will work well for other people as well, even if it won't work well for everyone.

With regards to D1 users who are unhappy with D2, I think that it makes some sense to point out that a subset of D2 can be used in a way that's a lot like D1, but ultimately, if someone doesn't like the direction that D2 took, they're probably better off finding a language that better fits whatever it is that they're looking for in a language. Trying to convince someone to use a language that they don't like is likely to just make them unhappy.

- Jonathan M Davis