https://issues.dlang.org/show_bug.cgi?id=20808

moonlightsentinel@disroot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |moonlightsentinel@disroot.o
                   |                            |rg

--- Comment #1 from moonlightsentinel@disroot.org ---
Reduced example:

====================================
struct var
{
        @property opDispatch(string file, T)(T)
        // if (is(T==char))
        {}
}

void main()
{
        var globals;
        globals.printInt = 2;
}
===================================

Removing `string file` pr enabling the template constraints makes DMD issue a
proper error message:
=> main.d(12): Error: no property printInt for type main.var

--

https://issues.dlang.org/show_bug.cgi?id=20808

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--

https://issues.dlang.org/show_bug.cgi?id=20808

--- Comment #2 from Basile-z <b2.temp@gmx.com> ---
the reducted version is not good, dont take it to work on a fix.

It's is perfectly normal that it is accepted:

---
struct var
{
        @property void opDispatch(string file, T)(T t)
        //if (is(T==char))
        {
                assert(t == 2);
        }
}

void main()
{
        var globals;
        globals.printInt = 2;                 // this and
        globals.opDispatch!("printInt") = 2;  // that are the same
}
---

Then when the constraint is enabled, it's perfectly normal that the code is
rejected, i.e per convertion rules.
Finally when `string file` is missing, this is also rejected as expected
because the template cant dispatch the "printInt" pseduo member.

--

https://issues.dlang.org/show_bug.cgi?id=20808

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86_64                      |All
                 OS|Linux                       |All
           Severity|major                       |normal

--- Comment #3 from Basile-z <b2.temp@gmx.com> ---
Are you sure that this report is not rather invalid, e.g before 2.088 it used to be a reject-valid and now i t's accepted as expected ?

--

https://issues.dlang.org/show_bug.cgi?id=20808

--- Comment #4 from Adam D. Ruppe <destructionator@gmail.com> ---
It modifies a const inside the opAssign which is why it fails. That's not supposed to be allowed so the error should happen.

All opDispatch does is forward directly to opIndexAssign, so if opIndexAssign doesn't compile, opDispatch shouldn't either.

You can call the assigned function by adding

    globals.printInt()(); //  be sure to use double parens thanks @property

if you take that const off the function definition, it works fine in either case showing the assignment was successful. But the const back on and you get error in the direct opIndexAssign and... silence on opDispatch.

You can even do

    globals.opDispatch!"printInt" = &printInt;

to get the error.

--

https://issues.dlang.org/show_bug.cgi?id=20808

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com
           Severity|normal                      |regression

--

https://issues.dlang.org/show_bug.cgi?id=20808

--- Comment #5 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to Adam D. Ruppe from comment #4)
> It modifies a const inside the opAssign which is why it fails. That's not supposed to be allowed so the error should happen.
> 
> All opDispatch does is forward directly to opIndexAssign, so if opIndexAssign doesn't compile, opDispatch shouldn't either.
> 
> You can call the assigned function by adding
> 
>     globals.printInt()(); //  be sure to use double parens thanks @property
> 
> if you take that const off the function definition, it works fine in either case showing the assignment was successful. But the const back on and you get error in the direct opIndexAssign and... silence on opDispatch.
> 
> You can even do
> 
>     globals.opDispatch!"printInt" = &printInt;
> 
> to get the error.

I'm trying to fix this issue, but I am not able to reproduce it.

globals["printInt"] = &printInt;

compiles just fine for me. Is this issue still actual? Also, a smaller test case would help a lot in narrowing down the issue.

--

https://issues.dlang.org/show_bug.cgi?id=20808

--- Comment #6 from Adam D. Ruppe <destructionator@gmail.com> ---
"it compiles just fine" IS the bug. It suppresses an error that should have terminated the compilation.

--

https://issues.dlang.org/show_bug.cgi?id=20808

--- Comment #7 from Adam D. Ruppe <destructionator@gmail.com> ---
BTW also don't forget this related thing: https://issues.dlang.org/show_bug.cgi?id=14145

--

https://issues.dlang.org/show_bug.cgi?id=20808

--- Comment #8 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to Adam D. Ruppe from comment #6)
> "it compiles just fine" IS the bug. It suppresses an error that should have terminated the compilation.

What I was saying is that both:

globals.printInt = &printInt;
globals["printInt"] = &printInt;

are compiling.

--