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.

Reply via email to