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