[dmd-internals] Type mangling for deduced attributes

[Steven Schveighoffer]

IMO, the fact that pure function pointers don't implicitly cast to non-pure ones with equivalent args is a separate problem.  Same for @safe and nothrow.

-Steve

Sent from my iPhone

On Nov 18, 2011, at 3:04 AM, Don Clugston <dclugston at googlemail.com> wrote:

> On 18 November 2011 04:48, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>> 
>> 
>>> ________________________________
>>> From: Don Clugston <dclugston at googlemail.com>
>>> 
>>> 
>>> No, I'm worried about noisy breaking of pure/nothrow. It can even go
>>> in the other direction. Delete a read from a static variable in the
>>> body of a template function (not the signature) and now your code
>>> won't link, because the function suddenly became pure. The issue is
>>> predictability.
>>> 
>> 
>> 
>> First, templates do *not* do well as stale objects or dynamically linked ones (this is from experience with C++).  I remember we had this great idea that we would standardize on std::string for a lot of things in a library at work, where things were dynamically linked.  One upgrade to libstdc++, and bizarro errors start occurring.  We eventually used stlport where we could control the string implementation to avoid surprises.
> 
> It affects more than templates.
> 
>> Second, you *want* the linking to fail if the object is stale.  What if purity or nothrow is *removed* by a change to a function?
> 
> That direction is fine. The idea behind the current implementation is,
> that if you don't have the source code to the function, then you
> _cannot_ rely on implicit purity. You only have purity if it's
> explicitly written in the source code.
> 
> Does the current implementation actually work? Kenji's example is a
> pretty strong argument that it doesn't. But that's the idea behind it.
> 
>> Bottom line, I don't think changing the signature of a function, whether implied or not, and not recompiling dependent code is a valid use case, or at least one we should care about.
> 
> The thing is, it includes code which wasn't dependent prior to the
> introduction of implied purity. For example, function pointers with
> implicit type deduction. External code doesn't need to be able to see
> the initializer, it only needs to know the type. Currently,
> automatically generated di files always include the initializers, and
> don't put in the deduced type. There'd be a huge speed increase if the
> initializers were dropped. But we're introducing cases where function
> bodies must be included, solely for type deduction.
> 
> This statement from Kenji is quite plausible:
>> But, conservative mangling of template function never rescue anything, IMO.
>> It just decrease the type information and cause inconsistent confusion.
> 
> I fear that this is right.