On Thursday, 6 October 2016 at 15:00:56 UTC, Manu wrote:
> On 6 October 2016 at 00:29, Manu <turkeyman@gmail.com> wrote:
>> On 4 October 2016 at 11:15, Manu <turkeyman@gmail.com> 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?

On 7 October 2016 at 05:58, Jinx via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 6 October 2016 at 15:00:56 UTC, Manu wrote:
>>
>> On 6 October 2016 at 00:29, Manu <turkeyman@gmail.com> wrote:
>>>
>>> On 4 October 2016 at 11:15, Manu <turkeyman@gmail.com> 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!");

On 7 October 2016 at 01:00, Manu <turkeyman@gmail.com> wrote:
> 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 ;)

Still blocked on this. Project on hold for almost a week! :(

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?

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.

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.

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.

On 9 October 2016 at 16:04, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> 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.