Jump to page: 1 2
Thread overview
inout delegate
Oct 02, 2016
Manu
Oct 02, 2016
Timon Gehr
Oct 03, 2016
Manu
Oct 03, 2016
Jacob Carlborg
Oct 03, 2016
Manu
Oct 04, 2016
Timon Gehr
Oct 04, 2016
Manu
Oct 05, 2016
Manu
Oct 06, 2016
Manu
Oct 06, 2016
Jinx
Oct 07, 2016
Manu
Oct 09, 2016
Nicholas Wilson
Oct 09, 2016
Adam D. Ruppe
Oct 09, 2016
Nicholas Wilson
Oct 09, 2016
Manu
Oct 08, 2016
Manu
Oct 09, 2016
Nicholas Wilson
October 02, 2016
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?
October 02, 2016
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
October 02, 2016
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()'.)
October 03, 2016
On 3 October 2016 at 02:00, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> 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
October 03, 2016
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
October 03, 2016
On 3 October 2016 at 17:18, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> 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.
October 04, 2016
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.
October 04, 2016
On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> 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...
October 06, 2016
On 4 October 2016 at 11:15, Manu <turkeyman@gmail.com> wrote:
> On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> 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?
October 07, 2016
On 6 October 2016 at 00:29, Manu <turkeyman@gmail.com> wrote:
> On 4 October 2016 at 11:15, Manu <turkeyman@gmail.com> wrote:
>> On 4 October 2016 at 10:50, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> 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 ;)
« First   ‹ Prev
1 2