Rather D1 then D2

[Henrik]

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.