Greenwashing

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu May 28 22:56:15 UTC 2020


On 5/28/20 11:12 AM, Steven Schveighoffer wrote:
> On 5/28/20 10:53 AM, Joseph Rushton Wakeling wrote:
>> On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
>>> The beauty of inferred by default is neither are breaking changes.
>>
>> Not sure I agree about that TBH.  Inferred-by-default just means the 
>> function signature doesn't by default tell you anything about what 
>> properties you can rely on, and any change to the implementation may 
>> alter the available properties, without any external sign that this 
>> has happened.
> 
> 1. Templates already do this, and it has not been a problem (much of 
> Phobos and much of what I've written is generally templates).
> 
> 2. If we went to an "inferred-by-default" regime, there would have to be 
> a way to opt-out of it, to allow for crafting attributes of public 
> extern functions.
> 
> 3. You would still need to specify exact attributes for virtual functions.
> 
> 4. Documentation should show the inferred attributes IMO (not sure if 
> this already happens for auto functions for example).
> 
> 5. Yes, inferred attributes might change. This would be a breaking 
> change. It might be a breaking change for others where it is not for the 
> library/function in question. But it would still be something that IMO 
> would require a deprecation period. For things outside our control, it's 
> very possible that these changes would be done anyway even if they were 
> actual attributes.
> 
> 6. One might also take the view that a lack of attributes means the 
> function may or may not have those attributes inferred in the future 
> (i.e. it's not part of the API). I think much code is already written 
> this way.

Large projects separate compilation inter-procedural analysis does not 
scale yadda yadda yadda.



More information about the Digitalmars-d mailing list