On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis
wrote:
Personally, I'd much prefer that we not make this change. It's
just
shuffling things around in an attempt to make them more
consistent while
actually making them _less_ consistent.
- Jonathan M Davis
I don't think this problem is solvable without "dfix". Here are
the factors I would consider:
1. `@` is ugly. Therefore it would be great to make `safe`,
`trusted`, `system`, and `nogc` full-fledged keywords, to spare
future readers of code all those `@`s. So long as it's
definitely a permanent feature of the language, it should look as
good as possible. (`property` too, if we're sure it's not
leaving). `@` is then left exclusively for UDAs, an improvement,
IMO.
2. Consistency of attribute usage is important. All built-in
attributes should be markable in the same way, either with, or
without an `@` sign.
3. Singularity of usage also matters. There should only be one
way to mark a given attribute, either with or without `@`.
4. Old code matters. Existing code puts points 2 and 3 into
conflict.
Now it goes without saying that changing old code is a nuisance.
But it's important to point out that not all code changes are the
same. In the interest of furthering this discussion, here is a
list of the types of breaking changes, in my order of least to
most desirable:
B1. Silent breaking changes. Same code now does different things.
Rightly regarded as the worst kind. You don't even know what hit
you.
B2. Completely pointless changes. For the record, I'm against
changes which literally have no benefit. Most changes which get
seriously discussed, however, involve difficult tradeoffs, for
which the assumed benefit must outweigh the perceived loss, plus
the "switching costs". The point of this list is to emphasize
that not all switching costs are the same, and that they depend
greatly on the *individual* change.
B3. Breaking changes which require significant redesign of code.
Sociomantic faces this issue with their move to D2.
B4. Changes which can easily be fixed, with the right know-how.
Great error messages, referring the user to the documentation of
these changes and how to fix them, is essential.
B5. The kind that a tool such as 'dfix', can automate. For
example, let's say dfix is included with the compiler package.
Now you get an error, saying: "Error: `@nogc` is no longer
accepted, but can be automatically replaced with `nogc`. Run dfix
on this file? (y/n)"... or whatever is deemed the secure approach
to this feature.
B6. Changes which catch existing bugs, with no false positives.
Obviously wins.
The changes suggested in this thread are of kind 5.5. But more
people would have to get behind the whole 'dfix' approach for it
to work.
"Most D code is yet to be written. #PleaseBreakOurCode." +1
