This trivial code fails to compile with the error message:
`onlineapp.Test2.mxString!(oops).mxString` need `this` to access member `mxString`
```d
class Test2
{
string oops;
mixin(mxString!(oops));
}
enum mxString(alias c)()
{
return "";
}
```
This should compile as there is no dependent usage on "this". Plus, the message is obviously wrong as there is no member named `mxString`.
A real use case for that is:
```d
enum mxString(alias c)()
{
return typeof(c).stringof~" "~c.stringof~c.stringof~";";
}
```
Which does not depends on "this", as some code like `mxString!(typeof(oops), oops.stringof)` would work.
Mixin template does not have this limitation, so, I believe a normal function should not too.
Comment #1 by dfj1esp02 — 2022-08-01T15:20:08Z
The return type is wrong.
Comment #2 by msnmancini — 2022-08-08T15:16:43Z
Have you even tested the code?
Comment #3 by razvan.nitu1305 — 2022-08-09T12:50:35Z
(In reply to Marcelo Silva Nascimento Mancini from comment #0)
> This trivial code fails to compile with the error message:
> `onlineapp.Test2.mxString!(oops).mxString` need `this` to access member
> `mxString`
>
> ```d
> class Test2
> {
> string oops;
> mixin(mxString!(oops));
> }
> enum mxString(alias c)()
> {
> return "";
> }
> ```
>
> This should compile as there is no dependent usage on "this". Plus, the
> message is obviously wrong as there is no member named `mxString`.
>
> A real use case for that is:
> ```d
> enum mxString(alias c)()
> {
> return typeof(c).stringof~" "~c.stringof~c.stringof~";";
> }
> ```
> Which does not depends on "this", as some code like `mxString!(typeof(oops),
> oops.stringof)` would work.
>
> Mixin template does not have this limitation, so, I believe a normal
> function should not too.
I don't really understand what you are trying to achieve here? mixin templates are used to insert declarations in a scope. If you want to mixin a function, why not declare mxString as:
```
class Test2
{
string oops;
mixin mxTempl!(oops);
}
mixin template mxTempl(alias c)
{
enum mxString()
{
return "";
}
}
```
This is an enhancement request at best. However, I don't really see the point of this code. Why would you want to insert a publicly declared template in the scope of an aggregate? Why not just call the function template when it is needed with the appropriate template parameter?
Comment #4 by msnmancini — 2022-08-09T15:11:41Z
(In reply to RazvanN from comment #3)
> (In reply to Marcelo Silva Nascimento Mancini from comment #0)
> > This trivial code fails to compile with the error message:
> > `onlineapp.Test2.mxString!(oops).mxString` need `this` to access member
> > `mxString`
> >
> > ```d
> > class Test2
> > {
> > string oops;
> > mixin(mxString!(oops));
> > }
> > enum mxString(alias c)()
> > {
> > return "";
> > }
> > ```
> >
> > This should compile as there is no dependent usage on "this". Plus, the
> > message is obviously wrong as there is no member named `mxString`.
> >
> > A real use case for that is:
> > ```d
> > enum mxString(alias c)()
> > {
> > return typeof(c).stringof~" "~c.stringof~c.stringof~";";
> > }
> > ```
> > Which does not depends on "this", as some code like `mxString!(typeof(oops),
> > oops.stringof)` would work.
> >
> > Mixin template does not have this limitation, so, I believe a normal
> > function should not too.
>
> I don't really understand what you are trying to achieve here? mixin
> templates are used to insert declarations in a scope. If you want to mixin a
> function, why not declare mxString as:
>
> ```
> class Test2
> {
> string oops;
> mixin mxTempl!(oops);
>
> }
>
> mixin template mxTempl(alias c)
> {
> enum mxString()
> {
> return "";
> }
> }
> ```
>
> This is an enhancement request at best. However, I don't really see the
> point of this code. Why would you want to insert a publicly declared
> template in the scope of an aggregate? Why not just call the function
> template when it is needed with the appropriate template parameter?
Because I don't want to deal with mixin template overloads. When they are executed, its overloads becomes inside them, so, I'm doing a code for using string mixin instead. If I wish to generate the overloads using mixin template, I must do `alias overload = mixed.overload;` for each function defined inside it.
If I wish to iterate through its overloads and alias to them, I must do a named mixin template, which will actually be inserted on its namespace. This can be solved by doing another mixin template which actually executes a static foreach over members from the named mixin template and generate the alias declarations. This is literally fighting the language.
Comment #5 by boris2.9 — 2022-08-10T00:31:07Z
I think this is a known bug, there are some reports in the past of similar compiler behavior.
Related issues 17435, 18969, 20077, 22497.
Put 'static' in the definition as a workaround.
static enum mxString(alias c)()
{
return "";
}
Comment #6 by robert.schadek — 2024-12-13T19:24:04Z