dip1000 and preview in combine to cause extra safety errors

[Adam D Ruppe]

On Wednesday, 15 June 2022 at 10:49:13 UTC, Dukc wrote:
> This would be outright poison for a stable API or ABI of a 
> library, probably including ARSD. All your public functions 
> have attributes added to them under your nose, and then you 
> cannot change them without breaking client code because it 
> depends on those attributes you did not intend to add.

My view of this (which I need to write about in more detail in 
the blog, but I have 1,000 more lines of code to translate for 
work..... by tomorrow...... yeah im not gonna make the deadline 
but still wanna get as close as i can, so blog on hold for a bit) 
is that the explicit attributes are all that'd count for 
breakage, and the inferred ones are specifically subject to 
change at any time and people shouldn't rely on them. The 
auto-generated .di file might list it, but the documentation 
absolutely would not.

I suppose some users might want to statically guarantee they are 
only using the stable published interface instead of the unstable 
inferred one, and that would be a bit tricky to declare given the 
attributes are part of the abi too. That's one of the things that 
needs more consideration.


> Even in a top-level application it happens every now and then 
> that I intentionally want to disable some attributes from a 
> function.

It is obvious to me that everything that can be turned on needs 
to be able to be turned off.

tbh it is one if the biggest embarrassments of the attribute soup 
process we have right now that there STILL isn't a `@gc` or 
`impure` or whatever after all these years. Even the lowest 
hanging fruit out of this mess is in limbo.