[dmd-internals] Type mangling for deduced attributes

[Don Clugston]

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.