Things that make writing a clean binding system more difficult

[Timon Gehr via Digitalmars-d]

On 29.07.2016 08:51, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, July 29, 2016 08:29:19 Timon Gehr via Digitalmars-d wrote:
>> On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:
>>> On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
>>>> My parser accepts the following:
>>>>
>>>> int function(int,int)ref functionPointer;
>>>>
>>>> I wasn't really aware that this was illegal in DMD. (Other function
>>>> attributes, such as pure, are accepted.)
>>>>
>>>> In fact, even the following is disallowed:
>>>> int foo(int)ref{}
>>>>
>>>>
>>>> Should I file an enhancement request?
>>>
>>> Except that ref isn't a function attribute.
>>
>> Yes it is.
>>
>> int x;
>> ref{
>>      int foo(){ return x;}
>> }
>> pragma(msg, typeof(&foo()));
>
> That's downright bizzarre given that ref applies to the return type and not
> to the this pointer (and that function doesn't even have a this pointer,
> since it's not a member function).
> ...

It does not apply to the return type. There is actually no way to tell 
whether a function returns ref or not by just examining the return type. 
It's the function which is ref.

>>> It's an attribute on the return type.
>>
>> There is no such thing. Types cannot have attributes.
>
> Sure they can. e.g.
>
> auto func(ref int param) {...}
>
> The same with in and out. They apply to the type of the parameter without
> actually being part of it.
> ...

No, typeof(param) is int. The type is not changed at all. The attribute 
applies to the parameter declaration.

>>> So, it doesn't make sense for it to be on the right. That would be
>>> like having the const on the right-hand side of a member function apply to
>>> the return type rather than the function itself.
>>> ...
>>
>> You have it backwards.
>
> It looks to me like the compiler is treating ref in a schizophrenic manner
> given that when it's used on a parameter, it treats it as part of the
> parameter, whereas with the return type, it's treating it as a function
> attribute instead of associating it with the return type. I'd guess that
> that stems from the fact that while ref is really supposed to be associated
> with the type, it's not actually part of the type.
>
> - Jonathan M Davis
>

'ref' has nothing to do with the type. This is not C++.

The only thing that is inconsistent here is that 'ref' is not accepted 
on the right for function declarations.