On Tue, 02 Sep 2014 13:15:01 +0000 Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> For example, this specific syntax is absolutely guaranteed to > result in weird issues because it is ambiguous with already > existing one (that applies attributes to declarations). ah, you talking about `@trusted { ... }`, right? why it is ambiguous? i applied one restriction to it: @trusted block must always be "{}"-blocks. that removes ambiguity altogether. it's not about saving some chars, it's about not writing arcane constructs like: () @trusted { ... }(); this looks weird. but hell with that "trusted blocks", how about foreach i mentioned? not accepting 'auto' in `foreach (auto i; 0..42)` is just illogical. here we saving 5 chars for... for what? `foreach (i; 0..42)` looks exactly like `for (i = 0; i < 42; ++i)`, yet it means something completely different. i understand that we can't make 'auto' mandatory there, but why don't make it at least acceptable? (and then add a deprecation warning, and then finally make 'auto' mandatory) as the time passing it becomes increasingly hard to fix this "cosmetic issues", as there are more and more people writing D code. i don't believe that waiting for another year or three and then just saying "alas, this train is gone long ago so now we must live with this legacy" is a good solution. yes, i'm relatively new in D world and my position may look like extremist one, but all i want is to make D better. that's why i'm writing those posts instead of sitting silently in my shell. i know that we can't change C or C++, but i believe that we can change D. not by throwing in random features, but by making D more consistent, better looking and more pleasant to use.
signature.asc
Description: PGP signature