Re: inout delegate
On 9 October 2016 at 16:04, Nicholas Wilson via Digitalmars-d
wrote:
> On Friday, 7 October 2016 at 02:13:21 UTC, Manu wrote:
>>
>> Perhaps you'd like to give it a go ;)
>>
>> Something like:
>>
>> template delegateTypeForInoutMethod(T, string method)
>> {
>> alias delegateTypeForInoutMethod = [write lots of stuff here];
>> }
>>
>> struct S
>> {
>> inout(int)[] f(ref const(int) arg) inout pure nothrow { return [ arg ];
>> }
>> }
>>
>> static assert(delegateTypeForInoutMethod!(const(S), "f") ==
>> const(int)[] delegate(ref const(int)) pure nothrow, "You failed!");
>
>
> https://gist.github.com/thewilsonator/06fe58b06eb7b2d97a675f95bb4d3fac
>
> passes the static assert. Sorry for the ugly mess, I don't have much time to
> clean it up today.
>
> Lesson: never be afraid to resort to mixins.
stringof + mixin fails when there are default args... they don't
stringify properly.
Re: inout delegate
On Sunday, 9 October 2016 at 04:20:26 UTC, Nicholas Wilson wrote: Do you know the cause? i.e. would dustmiting/`git bisect` tell you anything you don't already know? On the bug report, I linked to the commit and a small patch that fixes the problem: https://github.com/dlang/dmd/commit/3c53a0fd9ed1b40f8dbeb75b4dfa11f6df5b3062#commitcomment-19312704 I'd just like one of the compiler devs to review it and see if that's actually the right thing to do.
Re: inout delegate
On Friday, 7 October 2016 at 02:13:21 UTC, Manu wrote:
Perhaps you'd like to give it a go ;)
Something like:
template delegateTypeForInoutMethod(T, string method)
{
alias delegateTypeForInoutMethod = [write lots of stuff here];
}
struct S
{
inout(int)[] f(ref const(int) arg) inout pure nothrow {
return [ arg ]; }
}
static assert(delegateTypeForInoutMethod!(const(S), "f") ==
const(int)[] delegate(ref const(int)) pure nothrow, "You
failed!");
https://gist.github.com/thewilsonator/06fe58b06eb7b2d97a675f95bb4d3fac
passes the static assert. Sorry for the ugly mess, I don't have
much time to clean it up today.
Lesson: never be afraid to resort to mixins.
Re: inout delegate
On Sunday, 2 October 2016 at 09:55:26 UTC, Manu wrote:
Can someone explain this to me?
class Test
{
inout(int) f() inout { return 10; }
void t()
{
f(); // calls fine with mutable 'this'
auto d = &this.f; // error : inout method Test.f is not
callable
using a mutable this
d();
}
}
That error message seems very unhelpful, and it's not true. Of
course an inout method is callable with a mutable 'this'...
I suspect that the problem is the type for the delegate;
"inout(int)
delegate()" doesn't leave anything for the type system to
resolve the
inout with.
I guess the expectation is that this delegate has it's
inout-ness
resolved when you capture the delegate:
is(typeof(&this.f) == int delegate())
Or if 'this' were const:
is(typeof(&this.f) == const(int) delegate())
But I get this unhelpful error instead.
What's the story here?
That doesn't compile for me (using ad4a81b), but I get a
different error message with an accompanying main
void main()
{
const ct = new Test();
ct.t();
auto at = new Test();
at.t();
immutable it = new Test();
it.t();
}
Error: mutable method Test.t is not callable using a
(const|immutable) object
Note t, not f.
Making t inout fixes this.
Re: inout delegate
On Friday, 7 October 2016 at 02:13:21 UTC, Manu wrote: Since this is a bug (and a very recent regression no less) Do you know the cause? i.e. would dustmiting/`git bisect` tell you anything you don't already know?
Re: inout delegate
On 7 October 2016 at 01:00, Manu wrote: > On 6 October 2016 at 00:29, Manu wrote: >> On 4 October 2016 at 11:15, Manu wrote: >>> On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d >>> wrote: On 03.10.2016 05:06, Manu via Digitalmars-d wrote: > > Okay, well my current project is blocked on this. I can't progress. > https://issues.dlang.org/show_bug.cgi?id=16572 Probably you can work around the issue using unsafe type casts. >>> >>> Mmm, I'll see how much work it is to detect the case to do such a cast... >> >> I'm really struggling with this issue.. multiple times a day. >> I can't find a reasonable workaround. casting, or trying to re-synth >> the delegate type from the function signature doesn't seem to be >> reasonable. I lose all the attributes, and storage class on parameters >> are an endless nuisance that should never have existed. Cloning the >> function signature verbatim, but with inout resolved seems to be >> really hard and probably buggy. >> I really just need this bug fixed... is it a particularly tricky fix? > > Goodnight. I'm really hoping I wake up tomorrow and someone has some > comment on this issue... > I'm a post about it every day. I'm completely blocked while this > regression stands ;) Still blocked on this. Project on hold for almost a week! :(
Re: inout delegate
On 7 October 2016 at 05:58, Jinx via Digitalmars-d
wrote:
> On Thursday, 6 October 2016 at 15:00:56 UTC, Manu wrote:
>>
>> On 6 October 2016 at 00:29, Manu wrote:
>>>
>>> On 4 October 2016 at 11:15, Manu wrote:
[...]
>>>
>>>
>>> I'm really struggling with this issue.. multiple times a day.
>>> I can't find a reasonable workaround. casting, or trying to re-synth
>>> the delegate type from the function signature doesn't seem to be
>>> reasonable. I lose all the attributes, and storage class on parameters
>>> are an endless nuisance that should never have existed. Cloning the
>>> function signature verbatim, but with inout resolved seems to be
>>> really hard and probably buggy.
>>> I really just need this bug fixed... is it a particularly tricky fix?
>>
>>
>> Goodnight. I'm really hoping I wake up tomorrow and someone has some
>> comment on this issue...
>> I'm a post about it every day. I'm completely blocked while this
>> regression stands ;)
>
>
> Why not make a template function that does the necessary conversion? Going
> from the delegate to a void* then back again with the appropriate attributes
> applied by a cast?
storage class and attributes are so hard to work with. It's a serious
pain to do what you suggest.
Since this is a bug (and a very recent regression no less), I just
want it fixed so I can get on with it. Writing massively complex
workarounds for it is just not worth the energy. Seriously, I'm sure I
could spend a whole day on it trying to cover all cases!
Perhaps you'd like to give it a go ;)
Something like:
template delegateTypeForInoutMethod(T, string method)
{
alias delegateTypeForInoutMethod = [write lots of stuff here];
}
struct S
{
inout(int)[] f(ref const(int) arg) inout pure nothrow { return [ arg ]; }
}
static assert(delegateTypeForInoutMethod!(const(S), "f") ==
const(int)[] delegate(ref const(int)) pure nothrow, "You failed!");
Re: inout delegate
On Thursday, 6 October 2016 at 15:00:56 UTC, Manu wrote: On 6 October 2016 at 00:29, Manu wrote: On 4 October 2016 at 11:15, Manu wrote: [...] I'm really struggling with this issue.. multiple times a day. I can't find a reasonable workaround. casting, or trying to re-synth the delegate type from the function signature doesn't seem to be reasonable. I lose all the attributes, and storage class on parameters are an endless nuisance that should never have existed. Cloning the function signature verbatim, but with inout resolved seems to be really hard and probably buggy. I really just need this bug fixed... is it a particularly tricky fix? Goodnight. I'm really hoping I wake up tomorrow and someone has some comment on this issue... I'm a post about it every day. I'm completely blocked while this regression stands ;) Why not make a template function that does the necessary conversion? Going from the delegate to a void* then back again with the appropriate attributes applied by a cast?
Re: inout delegate
On 6 October 2016 at 00:29, Manu wrote: > On 4 October 2016 at 11:15, Manu wrote: >> On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d >> wrote: >>> On 03.10.2016 05:06, Manu via Digitalmars-d wrote: Okay, well my current project is blocked on this. I can't progress. https://issues.dlang.org/show_bug.cgi?id=16572 >>> >>> >>> Probably you can work around the issue using unsafe type casts. >> >> Mmm, I'll see how much work it is to detect the case to do such a cast... > > I'm really struggling with this issue.. multiple times a day. > I can't find a reasonable workaround. casting, or trying to re-synth > the delegate type from the function signature doesn't seem to be > reasonable. I lose all the attributes, and storage class on parameters > are an endless nuisance that should never have existed. Cloning the > function signature verbatim, but with inout resolved seems to be > really hard and probably buggy. > I really just need this bug fixed... is it a particularly tricky fix? Goodnight. I'm really hoping I wake up tomorrow and someone has some comment on this issue... I'm a post about it every day. I'm completely blocked while this regression stands ;)
Re: inout delegate
On 4 October 2016 at 11:15, Manu wrote: > On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d > wrote: >> On 03.10.2016 05:06, Manu via Digitalmars-d wrote: >>> >>> Okay, well my current project is blocked on this. I can't progress. >>> https://issues.dlang.org/show_bug.cgi?id=16572 >> >> >> Probably you can work around the issue using unsafe type casts. > > Mmm, I'll see how much work it is to detect the case to do such a cast... I'm really struggling with this issue.. multiple times a day. I can't find a reasonable workaround. casting, or trying to re-synth the delegate type from the function signature doesn't seem to be reasonable. I lose all the attributes, and storage class on parameters are an endless nuisance that should never have existed. Cloning the function signature verbatim, but with inout resolved seems to be really hard and probably buggy. I really just need this bug fixed... is it a particularly tricky fix?
Re: inout delegate
On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d wrote: > On 03.10.2016 05:06, Manu via Digitalmars-d wrote: >> >> Okay, well my current project is blocked on this. I can't progress. >> https://issues.dlang.org/show_bug.cgi?id=16572 > > > Probably you can work around the issue using unsafe type casts. Mmm, I'll see how much work it is to detect the case to do such a cast...
Re: inout delegate
On 03.10.2016 05:06, Manu via Digitalmars-d wrote: Okay, well my current project is blocked on this. I can't progress. https://issues.dlang.org/show_bug.cgi?id=16572 Probably you can work around the issue using unsafe type casts.
Re: inout delegate
On Monday, 3 October 2016 at 02:47:09 UTC, Manu wrote: On 3 October 2016 at 02:37, Timon Gehr via Digitalmars-d This is a known issue: https://issues.dlang.org/show_bug.cgi?id=3720 (What I do is: typeof(&typeof(this).f) is int delegate(), but auto x = &f does not compile as the 'this' reference is missing.) It compiles for me... (using yesterday's nightly) I pasted it right from my code. It wouldn't compile using Timon's frontend, which was his point. — David
Re: inout delegate
On 3 October 2016 at 17:18, Jacob Carlborg via Digitalmars-d wrote: > On 2016-10-03 05:06, Manu via Digitalmars-d wrote: > >> Okay, well my current project is blocked on this. I can't progress. >> https://issues.dlang.org/show_bug.cgi?id=16572 > > > I You can remove "inout" ;) That just makes a different problem, ie, the one that requires it to be inout in the first place.
Re: inout delegate
On 2016-10-03 05:06, Manu via Digitalmars-d wrote: Okay, well my current project is blocked on this. I can't progress. https://issues.dlang.org/show_bug.cgi?id=16572 I You can remove "inout" ;) -- /Jacob Carlborg
Re: inout delegate
On 3 October 2016 at 02:00, Steven Schveighoffer via Digitalmars-d
wrote:
> On 10/2/16 2:55 AM, Manu via Digitalmars-d wrote:
>>
>> Can someone explain this to me?
>>
>> class Test
>> {
>> inout(int) f() inout { return 10; }
>>
>> void t()
>> {
>> f(); // calls fine with mutable 'this'
>> auto d = &this.f; // error : inout method Test.f is not callable
>> using a mutable this
>> d();
>> }
>> }
>>
>> That error message seems very unhelpful, and it's not true. Of course
>> an inout method is callable with a mutable 'this'...
>>
>> I suspect that the problem is the type for the delegate; "inout(int)
>> delegate()" doesn't leave anything for the type system to resolve the
>> inout with.
>> I guess the expectation is that this delegate has it's inout-ness
>> resolved when you capture the delegate:
>> is(typeof(&this.f) == int delegate())
>> Or if 'this' were const:
>> is(typeof(&this.f) == const(int) delegate())
>
>
> I think this is a bug, and I 100% agree with you. The type of the delegate
> should be based on the mutability of 'this'.
>
> The error message probably stems from logic that was meant to prevent
> invalid const/immutable delegate capture, but inout wasn't thought of.
>
> -Steve
Okay, well my current project is blocked on this. I can't progress.
https://issues.dlang.org/show_bug.cgi?id=16572
Re: inout delegate
On 3 October 2016 at 02:37, Timon Gehr via Digitalmars-d
wrote:
> On 02.10.2016 13:27, Manu via Digitalmars-d wrote:
>>
>> And what's the logic behind this:
>>
>> class Test
>> {
>> int f() { return 10; }
>>
>> static assert(is(typeof(&typeof(this).f) == int function())); // huh?
>>
>> static void t()
>> {
>> // as expected:
>> f(); // error : need 'this' for 'f' of type 'int()'
>>
>> // calling a method without a context pointer...
>> auto x = &f;
>> x(); // call the method with no context pointer, how is this okay?
>>
>> pragma(msg, typeof(x)); // prints: int function()
>> }
>> }
>>
>> If f() were supplied an argument, the function would receive the first
>> arg as the context pointer, and the rest would be out by 1! O_o
>> I don't see how this code can be acceptable?
>>
>> If such a thing (getting a static function pointer from a delegate)
>> were to be supported, surely: is(typeof(&Test.f) == int
>> function(Test)), though this is only valid for some (most) abi's.
>
>
> This is a known issue: https://issues.dlang.org/show_bug.cgi?id=3720
>
> (What I do is: typeof(&typeof(this).f) is int delegate(), but auto x = &f
> does not compile as the 'this' reference is missing.)
It compiles for me... (using yesterday's nightly)
I pasted it right from my code.
Re: inout delegate
On 02.10.2016 13:27, Manu via Digitalmars-d wrote:
And what's the logic behind this:
class Test
{
int f() { return 10; }
static assert(is(typeof(&typeof(this).f) == int function())); // huh?
static void t()
{
// as expected:
f(); // error : need 'this' for 'f' of type 'int()'
// calling a method without a context pointer...
auto x = &f;
x(); // call the method with no context pointer, how is this okay?
pragma(msg, typeof(x)); // prints: int function()
}
}
If f() were supplied an argument, the function would receive the first
arg as the context pointer, and the rest would be out by 1! O_o
I don't see how this code can be acceptable?
If such a thing (getting a static function pointer from a delegate)
were to be supported, surely: is(typeof(&Test.f) == int
function(Test)), though this is only valid for some (most) abi's.
This is a known issue: https://issues.dlang.org/show_bug.cgi?id=3720
(What I do is: typeof(&typeof(this).f) is int delegate(), but auto x =
&f does not compile as the 'this' reference is missing.)
Re: inout delegate
On 02.10.2016 18:00, Steven Schveighoffer wrote:
On 10/2/16 2:55 AM, Manu via Digitalmars-d wrote:
Can someone explain this to me?
class Test
{
inout(int) f() inout { return 10; }
void t()
{
f(); // calls fine with mutable 'this'
auto d = &this.f; // error : inout method Test.f is not callable
using a mutable this
d();
}
}
That error message seems very unhelpful, and it's not true. Of course
an inout method is callable with a mutable 'this'...
I suspect that the problem is the type for the delegate; "inout(int)
delegate()" doesn't leave anything for the type system to resolve the
inout with.
I guess the expectation is that this delegate has it's inout-ness
resolved when you capture the delegate:
is(typeof(&this.f) == int delegate())
Or if 'this' were const:
is(typeof(&this.f) == const(int) delegate())
I think this is a bug, and I 100% agree with you. The type of the
delegate should be based on the mutability of 'this'.
The error message probably stems from logic that was meant to prevent
invalid const/immutable delegate capture, but inout wasn't thought of.
-Steve
Definitely a bug. (My frontend implementation accepts the code and
correctly determines the delegate type as 'int delegate()'.)
Re: inout delegate
On 10/2/16 2:55 AM, Manu via Digitalmars-d wrote:
Can someone explain this to me?
class Test
{
inout(int) f() inout { return 10; }
void t()
{
f(); // calls fine with mutable 'this'
auto d = &this.f; // error : inout method Test.f is not callable
using a mutable this
d();
}
}
That error message seems very unhelpful, and it's not true. Of course
an inout method is callable with a mutable 'this'...
I suspect that the problem is the type for the delegate; "inout(int)
delegate()" doesn't leave anything for the type system to resolve the
inout with.
I guess the expectation is that this delegate has it's inout-ness
resolved when you capture the delegate:
is(typeof(&this.f) == int delegate())
Or if 'this' were const:
is(typeof(&this.f) == const(int) delegate())
I think this is a bug, and I 100% agree with you. The type of the
delegate should be based on the mutability of 'this'.
The error message probably stems from logic that was meant to prevent
invalid const/immutable delegate capture, but inout wasn't thought of.
-Steve
Re: inout delegate
And what's the logic behind this:
class Test
{
int f() { return 10; }
static assert(is(typeof(&typeof(this).f) == int function())); // huh?
static void t()
{
// as expected:
f(); // error : need 'this' for 'f' of type 'int()'
// calling a method without a context pointer...
auto x = &f;
x(); // call the method with no context pointer, how is this okay?
pragma(msg, typeof(x)); // prints: int function()
}
}
If f() were supplied an argument, the function would receive the first
arg as the context pointer, and the rest would be out by 1! O_o
I don't see how this code can be acceptable?
If such a thing (getting a static function pointer from a delegate)
were to be supported, surely: is(typeof(&Test.f) == int
function(Test)), though this is only valid for some (most) abi's.
On 2 October 2016 at 19:55, Manu wrote:
> Can someone explain this to me?
>
> class Test
> {
> inout(int) f() inout { return 10; }
>
> void t()
> {
> f(); // calls fine with mutable 'this'
> auto d = &this.f; // error : inout method Test.f is not callable
> using a mutable this
> d();
> }
> }
>
> That error message seems very unhelpful, and it's not true. Of course
> an inout method is callable with a mutable 'this'...
>
> I suspect that the problem is the type for the delegate; "inout(int)
> delegate()" doesn't leave anything for the type system to resolve the
> inout with.
> I guess the expectation is that this delegate has it's inout-ness
> resolved when you capture the delegate:
> is(typeof(&this.f) == int delegate())
> Or if 'this' were const:
> is(typeof(&this.f) == const(int) delegate())
>
> But I get this unhelpful error instead.
>
> What's the story here?
