RFC: DIP draft for "Compiler-defined Attribute Consistency"
Rune Morling
ermo at serpentos.com
Wed Jul 21 20:00:32 UTC 2021
On Saturday, 17 July 2021 at 10:51:20 UTC, Dennis wrote:
> On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:
>> Comments very welcome.
>
> I just noticed there is an issue for this:
> https://issues.dlang.org/show_bug.cgi?id=13388
>
> And a discussion:
> https://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org
>
> And a PR that got merged:
> https://github.com/dlang/dmd/pull/4341
>
> But reverted because there was no consensus in the discussion
> yet:
> https://github.com/dlang/dmd/pull/4349
Thank you for the investigation and for listing the prior
discussions.
I've read all of it and the most pertinent summary of the
situation I could find was this:
> The problem is that no proposal has been given which really
> makes the attribute names
> consistent in a way that makes sense to actually change to.
> We may agree that the status quo is ugly, but how things should
> be changed is not
> at all clear. So, we don't even know how we'd want to change
> the language to fix
> the attribute situation.
>
> And even if dfix makes it easy to change code, breaking code
> still causes problems.
> So, while dfix will definitely help reduce the pain when we do
> decide to make changes
> to the language which will require changing existing code, it
> doesn't make the language
> changes free. The fact that dfix could make it easy to change
> existing code does not
> mean that it's okay to make breaking changes without a very
> good reason behind them.
>
> [source](https://issues.dlang.org/show_bug.cgi?id=13388#c33)
In other words, unless I/we can come up with an "algorithm" for
deciding when something should be an @-attribute, the DIP I've
proposed has little merit in that it's basically just proposing
that we shuffle attributes around on a whim.
Personally, I'm currently leaning towards something that
describes how a keyword/attribute changes the amount of checks
that the compiler makes so that it's akin to switching to a
different "mode" of compilation with attendant extra/fewer
checks/limits on functions.
More information about the Digitalmars-d
mailing list