On Wednesday, January 28, 2015 16:10:28 via Digitalmars-d wrote: > On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis > wrote: > > inconsistencies and annoying points in the language. And much > > of the time, > > those inconsistencies and annoying points are forced by other > > aspects of the > > language that actually make things nice and clean. There are > > always > > tradeoffs, and often, there is no clear, right answer to how it > > should be. > > I think I misinterpreted what you meant to say, but if the > semantics are good and sound then you should be able to device a > consistent syntax for the language that is in line with current > terminology in comp sci (even if that means pointing to Wikipedia > for a definition of the term). > > That would of course mean a lot of changes to D terminology: > > "const" => "readonly" > "enum" => "const" > "range"=>"iterator" > "pure"=>"no global effect" > "ubyte" => "byte" > "lazy" => "by name" > etc...
I don't see what any of that has to do with which attributes have @ on them or not. The problem is that any situation where some of the attributes have @ and some don't is going to cause some confusion, whereas putting @ on all of them would create inconsistencies with the expectations of folks coming from other languages and make porting code to D more annoying, and putting @ on none of them means that we're consistent but would mean that every time that we had to introduce a new built-in attribute (which we don't want to do much more of, but it still happens occasionally), we would either break existing code (because it would mean introducing a new keyword), or we'd have to put @ on it (making things inconsistent again, but only risking breaking UDA code, which is less prevalent). If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put @ on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes. And even then, instead of getting complaints about being inconsistent with @, then we'd get even more complaints about the number of keywords that we have. There is no way to win here. No matter what we do, there will be screaming from someone. And whether the language would be objectively improved would be debatable. There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better. - Jonathan M Davis
