Type mangling for deduced attributes (page 3)

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.

Forums