On Friday, May 04, 2012 11:38:32 Manu wrote:
> I try rearranging the syntax to make the first issue stop complaining:
> 
> ref const(Thing) func2() { return gThing; } // this seems to work now, but
> i don't like the inconsistency...

That's thanks to the nonsense that putting const on the left-hand side of a 
member function is legal, making it so that you _must_ use parens with const 
and return types for the const to apply to the return type rather than the 
function.

> ref const(Thing) function() blah2 = &func;
> 
> Error: variable remedy.hud.blah2 only parameters or foreach declarations
> can be ref

Hmm. Well assuming that you can't fix the problem with parens (and I don't 
think that you can), you should probably use typeof. Either

typeof(ref const(Thing) function()) blah2 = &func;

will work (I'm not sure if it will), or if you have a function (e.g. foo) of 
type ref const(Thing) function(), then you could do

typeof(foo) blah2 = &func;

- Jonathan M Davis

On 4 May 2012 11:46, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Friday, May 04, 2012 11:38:32 Manu wrote:
> > I try rearranging the syntax to make the first issue stop complaining:
> >
> > ref const(Thing) func2() { return gThing; } // this seems to work now,
> but
> > i don't like the inconsistency...
>
> That's thanks to the nonsense that putting const on the left-hand side of a
> member function is legal, making it so that you _must_ use parens with
> const
> and return types for the const to apply to the return type rather than the
> function.
>
> > ref const(Thing) function() blah2 = &func;
> >
> > Error: variable remedy.hud.blah2 only parameters or foreach declarations
> > can be ref
>
> Hmm. Well assuming that you can't fix the problem with parens (and I don't
> think that you can), you should probably use typeof. Either
>
> typeof(ref const(Thing) function()) blah2 = &func2;
>

This fails quite spectacularly:
 remedy\modules\hud.d(33):expression expected, not 'ref'
 remedy\modules\hud.d(33):found 'const' when expecting ')'
 remedy\modules\hud.d(33):function declaration without return type. (Note
that constructors are always named 'this')
 remedy\modules\hud.d(33):no identifier for declarator typeof(0)(Thing)
 remedy\modules\hud.d(33):semicolon expected following function declaration
 remedy\modules\hud.d(33):Declaration expected, not 'function'



> will work (I'm not sure if it will), or if you have a function (e.g. foo)
> of
> type ref const(Thing) function(), then you could do
>
> typeof(foo) blah2 = &foo;
>

This also fails:
 Error: variable remedy.hud.blah2 cannot be declared to be a function

>_<

On 4 May 2012 11:46, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> typeof(foo) blah2 = &func;
>

I just spotted the problem:
typeof(&foo) blah = &foo;

Was missing the '&' before the type. This works... However, in my case, I
don't have such a function defined to copy the type from, so it doesn't
help me any :/

Jonathan M Davis:

> That's thanks to the nonsense that putting const on the 
> left-hand side of a
> member function is legal, making it so that you _must_ use 
> parens with const
> and return types for the const to apply to the return type 
> rather than the function.

In Phobos there is a closed enhancement request about this. I 
suggest to add to that closed thread all the troubles/bugs we 
find in the forums. Maybe eventually Walter will change his mind 
on this.

Bye,
bearophile

On Fri, May 04, 2012 at 01:46:21AM -0700, Jonathan M Davis wrote:
> On Friday, May 04, 2012 11:38:32 Manu wrote:
> > I try rearranging the syntax to make the first issue stop complaining:
> > 
> > ref const(Thing) func2() { return gThing; } // this seems to work now, but
> > i don't like the inconsistency...
> 
> That's thanks to the nonsense that putting const on the left-hand side
> of a member function is legal, making it so that you _must_ use parens
> with const and return types for the const to apply to the return type
> rather than the function.

Yeah, I've recently started building the habit of always using
parentheses with const applied to a type, in order to make it less
confusing with const as applied to a function. Even though it's legal to
write:

	int func(const T t) {...}

nowadays I prefer to write:

	int func(const(T) t) {...}

so that when you need to return const, the syntax is more consistent:

	const(T) func(const(T) t) {...}

and it doesn't visually clash so much with const as applied to the
function itself:

	const(T) func(const(T) t) const {...}

This is one of the warts in D syntax that I find annoying.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On 4 May 2012 16:53, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Fri, May 04, 2012 at 01:46:21AM -0700, Jonathan M Davis wrote:
> > On Friday, May 04, 2012 11:38:32 Manu wrote:
> > > I try rearranging the syntax to make the first issue stop complaining:
> > >
> > > ref const(Thing) func2() { return gThing; } // this seems to work now,
> but
> > > i don't like the inconsistency...
> >
> > That's thanks to the nonsense that putting const on the left-hand side
> > of a member function is legal, making it so that you _must_ use parens
> > with const and return types for the const to apply to the return type
> > rather than the function.
>
> Yeah, I've recently started building the habit of always using
> parentheses with const applied to a type, in order to make it less
> confusing with const as applied to a function. Even though it's legal to
> write:
>
>        int func(const T t) {...}
>
> nowadays I prefer to write:
>
>        int func(const(T) t) {...}
>
> so that when you need to return const, the syntax is more consistent:
>
>        const(T) func(const(T) t) {...}
>
> and it doesn't visually clash so much with const as applied to the
> function itself:
>
>        const(T) func(const(T) t) const {...}
>
> This is one of the warts in D syntax that I find annoying.
>

Yeah I really hate this too. I'd like to see const(T) strictly enforced,
considering the potential for ambiguity in other situations.

But I'm still stuck! :(
How can I do what I need to do?

On Fri, May 04, 2012 at 04:57:30PM +0300, Manu wrote:
> On 4 May 2012 16:53, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
[...]
> > Yeah, I've recently started building the habit of always using
> > parentheses with const applied to a type, in order to make it less
> > confusing with const as applied to a function. Even though it's
> > legal to write:
> >
> >        int func(const T t) {...}
> >
> > nowadays I prefer to write:
> >
> >        int func(const(T) t) {...}
> >
> > so that when you need to return const, the syntax is more
> > consistent:
> >
> >        const(T) func(const(T) t) {...}
> >
> > and it doesn't visually clash so much with const as applied to the
> > function itself:
> >
> >        const(T) func(const(T) t) const {...}
> >
> > This is one of the warts in D syntax that I find annoying.
> >
> 
> Yeah I really hate this too. I'd like to see const(T) strictly
> enforced, considering the potential for ambiguity in other situations.
> 
> But I'm still stuck! :(
> How can I do what I need to do?

Argh... this is really annoying. So I tried all sorts of combinations of
function pointer syntax in order to get the correct type for a ref
function that returns const(T), but couldn't. So I decided to let the
language tell me itself what the type is:

	import std.stdio;
	struct S {}
	ref const(S) func() { ... }
	void main() {
		auto fp = &func;
		writeln(typeid(fp));
	}

This program outputs:

	const(test.S)()*

So I copy-n-paste this type into the source:

	const(test.S)()* fp = &func;

and I get:

	test.d(15): function declaration without return type. (Note that constructors are always named 'this')
	test.d(15): no identifier for declarator const(test.S)()
	test.d(15): semicolon expected following function declaration

This is a language inconsistency, and very stupid.

But anyway, Walter was all fawning over voldemort types recently, so I
thought, well, apparently we have here another case of a voldemort type:
no matter what you try to call it, the compiler either doesn't
understand it or rejects it. So let's turn the language upon its own
head:

	typeof(&func) fp = &func;

And lo and behold, it works!! So it's very stupid, but if you at least
have an exemplary function that you'd like to make a function pointer
out of, you can use this workaround to name its type.

Yeah, I recommend filing a bug for this. The type of &func needs to be
nameable without resorting to using typeof(&func), but at least you can
use the latter as a temporary workaround until dmd is fixed. :-)


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are
perfectly safe; if you look at it the thousandth time, you are in
frightful danger of seeing it for the first time. -- G. K. Chesterton

On Fri, 04 May 2012 10:19:08 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx>  
wrote:

> Argh... this is really annoying. So I tried all sorts of combinations of
> function pointer syntax in order to get the correct type for a ref
> function that returns const(T), but couldn't. So I decided to let the
> language tell me itself what the type is:
>
> 	import std.stdio;
> 	struct S {}
> 	ref const(S) func() { ... }
> 	void main() {
> 		auto fp = &func;
> 		writeln(typeid(fp));
> 	}
>
> This program outputs:
>
> 	const(test.S)()*

This is a bug in druntime.  It should *never* print shit like this, we got  
rid of C-style function pointers.

try this instead when printing a type instead of typeid:

writeln(typeof(fp).stringof);

This can even be used at compile time:

pragma(msg, typeof(fp).stringof);

Result is:

const(S) function() ref

So let's try it!

void main()
{
   const(S) function() ref fp = &func;
}

typeidbug.d(6): no identifier for declarator const(S) function()
typeidbug.d(6): semicolon expected, not 'ref'

bleh, tried this too:

alias const(S) function() ref T;
...
T fp = &func;

typeidbug.d(4): found 'ref' when expecting '('
typeidbug.d(4): found ';' when expecting ')'
typeidbug.d(5): no identifier for declarator const(S) function(T)
typeidbug.d(5): semicolon expected to close alias declaration

this does work though:

alias typeof(&func) T;

So this type cannot be manually written, due to parsing ambiguities for  
ref.

So we got two bugs here:

1. you cannot manually write the type of such a function.
2. typeid(&func).toString() returns crap.

-Steve

On 05/04/12 15:57, Manu wrote:
> Yeah I really hate this too. I'd like to see const(T) strictly enforced, considering the potential for ambiguity in other situations.
> 
> But I'm still stuck! :(
> How can I do what I need to do?

If 'auto' is not an option:

  alias ref const(S) function() FT;
  FT fp;

(it's needed for things like 'extern (C)' too)

artur

On 2012-05-04 15:57, Manu wrote:

> But I'm still stuck! :(
> How can I do what I need to do?

Hmm, I think this starts to look like a voldemort type :) . A type which 
isn't possible to declare.

-- 
/Jacob Carlborg