[dmd-internals] Type mangling for deduced attributes

Don Clugston dclugston at googlemail.com
Thu Nov 17 06:38:22 PST 2011


On 17 November 2011 13:43, kenji hara <k.hara.pg at gmail.com> wrote:
> 2011/11/17 Don Clugston <dclugston at googlemail.com>:
>> On 17 November 2011 11:09, kenji hara <k.hara.pg at gmail.com> wrote:
>>> Withdraw a previous statement, I still argue that is better to apply
>>> result of inference into mangleof.
>>> First of all, the pure/safe/nothrow inference runs against only
>>> function literals and template functions.
>>
>> This is true at present. But are we confident that it will never apply
>> to anything else?
>>
>>> For function literal, its
>>> type determines in the place its written.For template function, its
>>> type determines in its instantiation.Both of cases can always see
>>> their function bodies.
>>
>> Are we happy to say that when full type inference is used, it does NOT
>> invoke safe/pure/nothrow inference?
>
> Template function instantiation and function literal type inference
> always also invoke attribute inference.
> They are inseparable.
>
>> immutable fptr = &foo!(7);
>> immutable fptr2 = (){ return 0; }
>>
>> That is, both fptr and fptr2 will always be impure, @system, and throw?
>> Or does it invoke safe/pure/nothrow inference? In which case the
>> situation I mentioned arises.
>
> Maybe you are worried about breaking pure/safe/nothrow-ness silently,
> but it does not happen.

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.

Absence of an attribute means either  "impure" _or_ "don't know/don't
care/please work it out for me". Somehow, we have to keep this
ambiguity out of external interfaces. It's not much of a problem with
safe, because we have the @system qualifier. But we have no @impure,
@maythrow -- there is no way to say, "this is *intentionally* not
pure, even if it's inferred as pure at the moment".

As Rainer says, it does seem odd to restrict purity inference to
templates functions and delegate literals. It would not be at all
difficult to implement it for functions as well. That would be nice,
because then code wouldn't need to be littered with annotations. As
far as I can tell, the only argument against doing it, is this
unpredictability problem. Arguably, the inference for templates
generates so much unpredicatibility, that we might as well extend it
to functions.

Something I should clarify -- I'm just playing devil's advocate here,
I don't actually have an opinion on what we should do.

> Because AutoDeclaration always invoke the semantics of its
> initializer, just for its type inference.
> Then, in types of fptr and fptr2, function type attributes should
> always be inferred based on their initializers.
> (I know bug 6963, current dmd does not invoke attribute inference of
> declaration in module level.)
>
> Through semantic processing over the modules, types and attributes are
> always guaranteed.
>
> Kenji Hara
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>


More information about the dmd-internals mailing list