Hi,
are there any news about this problem ?
This code does compile.
[code]
ref int min(ref int lhs,ref int rhs) {
return lhs rhs ? rhs : lhs;
}
auto fptr = min;
pragma(msg,typeof(fptr).stringof); //int function(ref int lhs,
ref int rhs) ref
[/code]
But how to manually specify type
On Wednesday, 19 February 2014 at 16:20:39 UTC, Remo wrote:
Hi,
are there any news about this problem ?
This code does compile.
[code]
ref int min(ref int lhs,ref int rhs) {
return lhs rhs ? rhs : lhs;
}
auto fptr = min;
pragma(msg,typeof(fptr).stringof); //int function(ref int lhs,
Looks like it's a bug.
How to report this bug ?
It is not possible to use auto because in real code the functions
are extern(C).
A workaround is: typeof(min) fprt = min;
Yes I already found this workaround, but it is really really ugly
this way.
private ref int __hidden_fn_1002(ref int
On Wednesday, 19 February 2014 at 17:01:15 UTC, Remo wrote:
Looks like it's a bug.
How to report this bug ?
It is not possible to use auto because in real code the
functions are extern(C).
Perhaps I'm missing something, but auto isn't incompatible with
extern(C)
Perhaps I'm missing something, but auto isn't incompatible with
extern(C)
What I mean is that I only need to define function pointer to a
function.
The function it self is extern and is a C++/C function.
On 02/19/14 17:20, Remo wrote:
This code does compile.
[code]
ref int min(ref int lhs,ref int rhs) {
return lhs rhs ? rhs : lhs;
}
auto fptr = min;
pragma(msg,typeof(fptr).stringof); //int function(ref int lhs, ref int rhs)
ref
[/code]
But how to manually specify type of
Excellent, this way is much better.
Thanks you artur.
On Wednesday, 19 February 2014 at 19:55:30 UTC, Artur Skawina
wrote:
On 02/19/14 17:20, Remo wrote:
This code does compile.
[code]
ref int min(ref int lhs,ref int rhs) {
return lhs rhs ? rhs : lhs;
}
auto fptr = min;
Remo remotio...@googlemail.com writes:
Looks like it's a bug.
How to report this bug ?
https://d.puremagic.com/issues/
Okay, here's another problem due to ref not being a type constructor.
If I have some function that receives an argument by ref, and then I take
parameterTypeTuple! of that functions parameter list, the ref bits are gone
from the typetuple.
If I give that tuple as a template arg, then the template
On 5/15/12 8:16 AM, Manu wrote:
Okay, here's another problem due to ref not being a type constructor.
If I have some function that receives an argument by ref, and then I
take parameterTypeTuple! of that functions parameter list, the ref bits
are gone from the typetuple.
If I give that tuple as
There's ParameterStorageClassTuple, which can say if it's a pointer-type
parameter (ref and out) or it's a delegate-type parameter (lazy). By
analyzing the storage classes of the parameters, one can transform T to T*
or T delegate() as necessary.
Indeed I did precisely this, when I wrote a
On 15 May 2012 16:28, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote:
On 5/15/12 8:16 AM, Manu wrote:
Okay, here's another problem due to ref not being a type constructor.
If I have some function that receives an argument by ref, and then I
take parameterTypeTuple! of that functions
On 05/05/12 01:32, Manu wrote:
On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com wrote:
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
On 5 May 2012 09:09, Artur Skawina art.08...@gmail.com wrote:
On 05/05/12 01:32, Manu wrote:
On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com mailto:
art.08...@gmail.com wrote:
On 05/04/12 15:57, Manu wrote:
Yeah I really hate this too. I'd like to see const(T) strictly
On 05/05/12 12:10, Manu wrote:
On 5 May 2012 09:09, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com wrote:
On 05/05/12 01:32, Manu wrote:
On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com mailto:art.08...@gmail.com
So here's some problems.
I use 'const ref' to pass structs to functions (note: because 'in ref'
doesn't seem to work)
And I often need to return structs by ref too, but I'm having problems:
void test( const ref Thing x ) {} // this works fine. note, 'const ref'
works fine here (in lieu of 'in
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
On 2012-05-04 10:38, Manu wrote:
So here's some problems.
I use 'const ref' to pass structs to functions (note: because 'in ref'
doesn't seem to work)
And I often need to return structs by ref too, but I'm having problems:
void test( const ref Thing x ) {} // this works fine. note, 'const ref'
On 4 May 2012 11:46, Jonathan M Davis jmdavisp...@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
On 4 May 2012 12:52, Jacob Carlborg d...@me.com wrote:
On 2012-05-04 10:38, Manu wrote:
This syntax complains, but it's precisely the same expression I use to
pass an argument in to a function, and it's fine there:
remedy\modules\hud.d(35):**Error: function remedy.hud.func without
'this'
On 4 May 2012 11:46, Jonathan M Davis jmdavisp...@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
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
On 2012-05-04 12:09, Manu wrote:
Ah, of course! I didn't spot that _
Thanks.
I suppose technically, 'ref' can lead to the same ambiguity. This must
be the core of the problem. ref needs to be supported with parentheses?
I'm not sure, since you can't declare a variable as ref I think the
On 4 May 2012 14:49, Jacob Carlborg d...@me.com wrote:
On 2012-05-04 12:09, Manu wrote:
Ah, of course! I didn't spot that _
Thanks.
I suppose technically, 'ref' can lead to the same ambiguity. This must
be the core of the problem. ref needs to be supported with parentheses?
I'm not
On Friday, 4 May 2012 at 11:49:44 UTC, Jacob Carlborg wrote:
On 2012-05-04 12:09, Manu wrote:
Ah, of course! I didn't spot that _
Thanks.
I suppose technically, 'ref' can lead to the same ambiguity.
This must
be the core of the problem. ref needs to be supported with
parentheses?
I'm not
On 05/04/2012 10:38 AM, Manu wrote:
So here's some problems.
I use 'const ref' to pass structs to functions (note: because 'in ref'
doesn't seem to work)
And I often need to return structs by ref too, but I'm having problems:
void test( const ref Thing x ) {} // this works fine. note, 'const
On Friday, 4 May 2012 at 12:45:23 UTC, Timon Gehr wrote:
This should work:
const(Thing) function()ref blah2 = func;
Except that it does not, because 'ref' is not currently a valid
function 'storage class'. This seems to be an issue that
deserves a bug report.
For ref functions, 'ref' is
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
On 4 May 2012 16:53, H. S. Teoh hst...@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;
On Fri, May 04, 2012 at 04:57:30PM +0300, Manu wrote:
On 4 May 2012 16:53, H. S. Teoh hst...@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
On 05/04/2012 03:00 PM, Jakob Ovrum wrote:
On Friday, 4 May 2012 at 12:45:23 UTC, Timon Gehr wrote:
This should work:
const(Thing) function()ref blah2 = func;
Except that it does not, because 'ref' is not currently a valid
function 'storage class'. This seems to be an issue that deserves a
On Fri, 04 May 2012 10:19:08 -0400, H. S. Teoh hst...@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
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
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
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
On 4 May 2012 18:07, Jakob Ovrum jakobov...@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
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
On 4 May 2012 18:55, Jakob Ovrum jakobov...@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
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;
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 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
On 2012-05-04 16:19, H. S. Teoh wrote:
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
On 2012-05-04 16:19, H. S. Teoh 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:
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
In Phobos there is a closed enhancement request about this.
http://d.puremagic.com/issues/show_bug.cgi?id=4070
I have added this case.
Bye,
bearophile
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
On Friday, 4 May 2012 at 08:46:38 UTC, 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...
On Friday, May 04, 2012 23:26:37 Peter Alexander wrote:
On Friday, 4 May 2012 at 08:46:38 UTC, 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
On 4 May 2012 23:16, Jakob Ovrum jakobov...@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
On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com wrote:
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
On 5 May 2012 02:32, Manu turkey...@gmail.com wrote:
On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com wrote:
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
On Saturday, May 05, 2012 02:30:00 Manu wrote:
On 4 May 2012 23:16, Jakob Ovrum jakobov...@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
On 5 May 2012 02:38, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Saturday, May 05, 2012 02:30:00 Manu wrote:
On 4 May 2012 23:16, Jakob Ovrum jakobov...@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
On Sat, May 05, 2012 at 02:33:44AM +0300, Manu wrote:
[...]
That said, I don't think it's a 'solution', I'm pretty sure there's a
bug somewhere in this thread, but I'm not sure how the syntax should
look... the problem seems rather complicated when considering
declaring functions, declaring
54 matches
Mail list logo
