Things that make writing a clean binding system more difficult

[Jonathan M Davis via Digitalmars-d]

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'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.

> > 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