I've stumbled over the fact that deduced function attributes (pure,
nothrow) are not reflected
in the name mangling. Is this a bug or by design?

This has some implications for functionAttributes in std.traits and also creates a compiler bug. http://d.puremagic.com/issues/show_bug.cgi?id=6600

martin

On 9/3/2011 5:56 PM, Martin Nowak wrote:
> I've stumbled over the fact that deduced function attributes (pure, nothrow)
> are not reflected
> in the name mangling. Is this a bug or by design?
>

It is by design. I think that's the right choice, but I'm not positive.

On Sun, 04 Sep 2011 03:44:19 +0200, Walter Bright <walter at digitalmars.com> wrote:

>
>
> On 9/3/2011 5:56 PM, Martin Nowak wrote:
>> I've stumbled over the fact that deduced function attributes (pure,
>> nothrow) are not reflected
>> in the name mangling. Is this a bug or by design?
>>
>
> It is by design. I think that's the right choice, but I'm not positive.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Well I see the point that it could be surprising for linkage.
I also understand that a function pointer to a function that is later
deduced to be pure nothrow gets a type of
pure nothrow. Tough to decide though.
I think as long as we stick with the current behavior we must prevent
TypeFunction from messing up the Type merging cache.

martin

2011/9/4 Walter Bright <walter at digitalmars.com>:
>
>
> On 9/3/2011 5:56 PM, Martin Nowak wrote:
>>
>> I've stumbled over the fact that deduced function attributes (pure,
>> nothrow) are not reflected
>> in the name mangling. Is this a bug or by design?
>>
>
> It is by design. I think that's the right choice, but I'm not positive.

I think .mangleof property should return the actual value (based on
the real type).
Otherwise, we cannot guarantee the pure/nothrow/safe attributes in ABI level.

But, to realize it dmd should implement full deferred semantic mechanism.
It would run its semantic3() with getting .mangleof property, even if
a target function declaration is in module level.

module test;
void foo()() {}
alias foo!() f;
pragma(msg, typeof(f).mangleof);
// Actually f has pure/nothrow/@safe attributes by their inference.
// But pragma prints "FZv", because instantiating foo!() in module
level does not run semantic3().
// To print "FNaNbNfZv", we need *full deferred semantic* mechanism, IMO.

Kenji Hara

On 16 November 2011 03:23, kenji hara <k.hara.pg at gmail.com> wrote:
> 2011/9/4 Walter Bright <walter at digitalmars.com>:
>>
>>
>> On 9/3/2011 5:56 PM, Martin Nowak wrote:
>>>
>>> I've stumbled over the fact that deduced function attributes (pure,
>>> nothrow) are not reflected
>>> in the name mangling. Is this a bug or by design?
>>>
>>
>> It is by design. I think that's the right choice, but I'm not positive.
>
> I think .mangleof property should return the actual value (based on
> the real type).
> Otherwise, we cannot guarantee the pure/nothrow/safe attributes in ABI level.

That's intentional. If it is only *deduced* to be pure/nothrow/safe,
then external functions, which don't have access to the source, can
NOT rely on it being pure/nothrow/safe. I think this is the right
choice.
Suppose I want to declare a stub function. At the moment, because it's
just a stub, it isn't impure or unsafe, but I know that when it is
fully implemented, it will be impure and unsafe, and may throw.
The deduction should not be giving additional guarantees to external
code. It should be conservative.

On 11/16/2011 12:31 AM, Don Clugston wrote:
>
> That's intentional. If it is only *deduced* to be pure/nothrow/safe,
> then external functions, which don't have access to the source, can
> NOT rely on it being pure/nothrow/safe. I think this is the right
> choice.
> Suppose I want to declare a stub function. At the moment, because it's
> just a stub, it isn't impure or unsafe, but I know that when it is
> fully implemented, it will be impure and unsafe, and may throw.
> The deduction should not be giving additional guarantees to external
> code. It should be conservative.

I think Don's reasoning is sound.

2011/11/16 Walter Bright <walter at digitalmars.com>:
>
> On 11/16/2011 12:31 AM, Don Clugston wrote:
>>
>> That's intentional. If it is only *deduced* to be pure/nothrow/safe,
>> then external functions, which don't have access to the source, can
>> NOT rely on it being pure/nothrow/safe. I think this is the right
>> choice.
>> Suppose I want to declare a stub function. At the moment, because it's
>> just a stub, it isn't impure or unsafe, but I know that when it is
>> fully implemented, it will be impure and unsafe, and may throw.
>> The deduction should not be giving additional guarantees to external
>> code. It should be conservative.
>
> I think Don's reasoning is sound.

Thanks for your explanations.
OK, It is reasonable.

Because of it, there is an issue caused by fixing 6902 with my patch. I'll post a pull to fix it.

kenji Hara

Take this argument with a grain of salt, I have very little internal dmd knowledge.? But...

Isn't deduction of pure/nothrow/safe restricted to templates?? Don't templates *require* availability of source?

Just saying...

-Steve




>________________________________
>From: kenji hara <k.hara.pg at gmail.com>
>To: Discuss the internals of DMD <dmd-internals at puremagic.com>
>Sent: Wednesday, November 16, 2011 5:24 AM
>Subject: Re: [dmd-internals] Type mangling for deduced attributes
>
>2011/11/16 Walter Bright <walter at digitalmars.com>:
>>
>> On 11/16/2011 12:31 AM, Don Clugston wrote:
>>>
>>> That's intentional. If it is only *deduced* to be pure/nothrow/safe,
>>> then external functions, which don't have access to the source, can
>>> NOT rely on it being pure/nothrow/safe. I think this is the right
>>> choice.
>>> Suppose I want to declare a stub function. At the moment, because it's
>>> just a stub, it isn't impure or unsafe, but I know that when it is
>>> fully implemented, it will be impure and unsafe, and may throw.
>>> The deduction should not be giving additional guarantees to external
>>> code. It should be conservative.
>>
>> I think Don's reasoning is sound.
>
>Thanks for your explanations.
>OK, It is reasonable.
>
>Because of it, there is an issue caused by fixing 6902 with my patch. I'll post a pull to fix it.
>
>kenji Hara
>_______________________________________________
>dmd-internals mailing list
>dmd-internals at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20111116/e499f5f3/attachment.html>

On 16.11.2011 15:35, Steve Schveighoffer wrote:
> Take this argument with a grain of salt, I have very little internal dmd knowledge.  But...
>
> Isn't deduction of pure/nothrow/safe restricted to templates?  Don't templates *require* availability of source?
>
> Just saying...
>
> -Steve
>

I think it would be an unexpected restricton to limit pure/nothrow/safe inference to templates. But if it is not, using di files instead of d files will break code because inference very much depends on whether the di-file generation emitted the code or not. Adding inferred attributes to  the function declarations could help but it currently changes the name mangling, breaking it again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20111117/404a558b/attachment.html>

On Thursday, November 17, 2011 07:51:24 Rainer Schuetze wrote:
> On 16.11.2011 15:35, Steve Schveighoffer wrote:
> > Take this argument with a grain of salt, I have very little internal dmd knowledge.  But...
> > 
> > Isn't deduction of pure/nothrow/safe restricted to templates?  Don't templates *require* availability of source?
> > 
> > Just saying...
> > 
> > -Steve
> 
> I think it would be an unexpected restricton to limit pure/nothrow/safe inference to templates. But if it is not, using di files instead of d files will break code because inference very much depends on whether the di-file generation emitted the code or not. Adding inferred attributes to  the function declarations could help but it currently changes the name mangling, breaking it again.

It's _already_ restricted to templates and delegates. You _need_ it for templates, since whether they can be pure, nothrow, or @safe depends on their arguments, and the only way to do that without inference is to duplicate the template a bunch of times with each possible combination of pur,e nothrow, and @safe. Normal functions, however, do _not_ need the inference. Whether they can be pure, nothrow, or @safe doesn't change unless you change according to their arguments.

In any case, I don't quite understand how this is an issue, since as Steve says, templates _require_ that their source be available.

- Jonathan M Davis