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