On 05/04/2012 04:53 PM, Jakob Ovrum wrote:
> On Friday, 4 May 2012 at 14:34:20 UTC, Timon Gehr wrote:
>> It is an attribute:
>>
>> int x;
>> ref {
>>     int foo(){ return x; }
>>     int bar(){ return x; }
>> }
>>
>> ref:
>>
>> int qux(){ return x; }
>>
>> static assert(typeof(&qux).stringof == "int function() ref");
>
> Thanks, this is news to me! I never noticed that ref was actually a
> function attribute.
>
> The following are legal declaration statements:
>
> extern(C) void function() foo;
> pure void function() bar; // not just linkage attributes
>
> So I think it's a plain bug that this isn't:
>
> ref void function() foo;
>
>

What would be the meaning of

void foo(ref void function() fn) { }

?

On Friday, 4 May 2012 at 14:57:14 UTC, Timon Gehr wrote:
>
> What would be the meaning of
>
> void foo(ref void function() fn) { }
>
> ?

Parameter storage classes can only go before the type, while function attributes can also go after the parameter list (of the function pointer or delegate for this case). So I would think that:

    void foo(ref void function() fn) { }

The above 'foo' would receive a function pointer by reference, while:

    void foo(void function() ref fn) { }

Would receive a function pointer which returns by ref.

On 4 May 2012 18:07, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Friday, 4 May 2012 at 14:57:14 UTC, Timon Gehr wrote:
>
>>
>> What would be the meaning of
>>
>> void foo(ref void function() fn) { }
>>
>> ?
>>
>
> Parameter storage classes can only go before the type, while function attributes can also go after the parameter list (of the function pointer or delegate for this case). So I would think that:
>
>
>    void foo(ref void function() fn) { }
>
> The above 'foo' would receive a function pointer by reference, while:
>
>    void foo(void function() ref fn) { }
>
> Would receive a function pointer which returns by ref.
>

It's very counter intuitive to mark the _function_ ref, rather than it's return type.

On Friday, 4 May 2012 at 15:49:03 UTC, Manu wrote:
> It's very counter intuitive to mark the _function_ ref, rather than it's
> return type.

It is a function attribute, so it makes perfect sense. The rest is an issue of documentation/education.

I agree it may not be optimally intuitive, but I don't see any superior syntactic options.

On 4 May 2012 18:55, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Friday, 4 May 2012 at 15:49:03 UTC, Manu wrote:
>
>> It's very counter intuitive to mark the _function_ ref, rather than it's return type.
>>
>
> It is a function attribute, so it makes perfect sense. The rest is an issue of documentation/education.
>
> I agree it may not be optimally intuitive, but I don't see any superior syntactic options.
>

Well, I personally see no reason not to allow 'ref' variables anywhere,
just like in C++. Breaking out pointers in D feels a bit dirty, by the same
reasoning that you use C++ references.
Why not make it a type modifier? It would just be a guaranteed initialised
pointer like in C++, and with no pointer assignment semantics.

On 2012-05-04 14:27, Manu wrote:

> You can declare a variable as ref in the parameter list, that's where
> the ambiguity could arise, same with const.

Yes, but I thought this was a variable of some kind and not a parameter.

-- 
/Jacob Carlborg

On 2012-05-04 17:55, Jakob Ovrum wrote:
> On Friday, 4 May 2012 at 15:49:03 UTC, Manu wrote:
>> It's very counter intuitive to mark the _function_ ref, rather than it's
>> return type.
>
> It is a function attribute, so it makes perfect sense. The rest is an
> issue of documentation/education.
>
> I agree it may not be optimally intuitive, but I don't see any superior
> syntactic options.

ref int a ();
const int b ();
const(int) c ();

"a" is function returning an int by reference.
"b" is a const function returning an int.
"c" is a function returning a const int.

Don't you see how it's confusing. Perhaps it would be better if "a" was declared like this:

ref(int) a ();

-- 
/Jacob Carlborg

On Friday, 4 May 2012 at 20:00:10 UTC, Jacob Carlborg wrote:
>
> ref int a ();
> const int b ();
> const(int) c ();

I fully understand the difference, it's a common source of confusion. But it also makes perfect sense if you know the rules about function attributes. I don't think it's optimal, but changing it now would break a lot of code, it cannot happen for D2. The best we can do is make 'ref' work properly as a function attribute by allowing it to occur after the parameter list.

'inout' also has this problem, but opposite; sometimes putting it in front of the member function makes it behave differently. I can't remember if there is a bug report for it (probably is... or maybe not, because nobody even expected inout to work at all a couple of versions ago).

> Perhaps it would be better if "a" was declared like this:
>
> ref(int) a ();

ref is not a type qualifier, I think that would be even more confusing. It would be completely out of sync with the rest of the language.

On 4 May 2012 23:16, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> Perhaps it would be better if "a" was declared like this:
>>
>> ref(int) a ();
>>
>
> ref is not a type qualifier, I think that would be even more confusing. It would be completely out of sync with the rest of the language.
>

But maybe it should be, then you'd be able to declare ref variables anywhere, like in C++... what's the disadvantage of that?

On Saturday, May 05, 2012 02:30:00 Manu wrote:
> On 4 May 2012 23:16, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> > Perhaps it would be better if "a" was declared like this:
> >> ref(int) a ();
> > 
> > ref is not a type qualifier, I think that would be even more confusing. It would be completely out of sync with the rest of the language.
> 
> But maybe it should be, then you'd be able to declare ref variables anywhere, like in C++... what's the disadvantage of that?

I know that Walter's against it, but unfortunately, I don't recall his arguments. But I'd certainly be very surprised if it ever happened.

- Jonathan M Davis