[Issue 19084] Symbol not resolved in string mixin in template struct
https://issues.dlang.org/show_bug.cgi?id=19084 Jonathan Marler changed: What|Removed |Added CC||johnnymar...@gmail.com --- Comment #1 from Jonathan Marler --- This is not supposed to compile. I've actually run into this before, but using T.stringof to mixin code for a type name is not supported. When I've asked about adding support for this, no one was interested. I tried to find my forum posts on this but the post is so old I couldn't find it in search. What happens is you mixin the string "Foo", but that type doesn't mean anyting in the scope of Bar. The actual type name is something like "__unittest__20.Foo", however, even if you got the fully qualified type name it won't work because the type is private and can't be accessed outside of the unittest using the symbol name. You have to access the type by "alias". The `bitfields` function in phobos suffers from this same problem and I created a PR in phobos to add bitfields2 to workaround this issue by using a "mixin template" instead of a normal "mixin": https://github.com/dlang/phobos/pull/5490 > [QUOTE FROM THE PR] > The main advantage of bitfields2 is that it is able to reference the field > types by alias, whereas the current implementation converts each field type > alias to a string and then mixes in the type name. I know the example you've provided is contrived so I'm not sure how to help you with your exact situation. Maybe I can help you find a solution with a bit more detail? --
[Issue 18917] Default Value for Function-Type Template Value-Parameter Causes Conflicts in Instantiation
https://issues.dlang.org/show_bug.cgi?id=18917 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #3 from Seb --- Definitely looks like a bug to me. --
[Issue 18672] Error in @safe transitive propagation with associative arrays
https://issues.dlang.org/show_bug.cgi?id=18672 --- Comment #5 from RazvanN --- PR : https://github.com/dlang/dmd/pull/8607 --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #15 from ag0aep6g ---
(In reply to Atila Neves from comment #13)
> > Apparently, DMD goes with infinite
>
> Only if it's a template this function.
No. My statement was about the lifetime of `malloc(...)`, which is called in
the constructor. The constructor doesn't have a template this parameter.
Your code has a template this parameter on the method `ptr`. But before `ptr`
comes into play, the lifetime of the field has already been set to infinite.
If we initialize the field to something with restricted lifetime, then leaking
`s.ptr` gets rejected as it should be:
const(int)* gInts;
void main() @safe
{
int x;
auto s = MyStruct();
gInts = s.ptr; /* Error: scope variable s assigned to gInts with longer
lifetime */
}
struct MyStruct
{
int* ints;
scope ptr(this This)() { return ints; }
}
The problem is that `ints` starts out with infinite lifetime when it's
initialized with a `malloc` call. `ptr` just passes the wrong lifetime on.
Also, if anything, it's the inference of the `return` attribute that's the
problem. The template this parameter merely triggers that. Empty template
parentheses or an `auto` return type have the same effect.
> As mentioned before, writing out the
> explicit instantitations for mutable, const and immutable doesn't compile.
[...]
> dmd is already doing the right thing with `scope ptr() { return ints; }`,
> `scope ptr() const { return ints; }` and `scope ptr() immutable { return
> ints; }` even if it's `auto s = MyStruct(10)` instead of `scope s =
> MyStruct(10)`.
As mentioned before, I can't reproduce this. Please post complete code.
With those definitions for `ptr` I get this code:
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct(10);
gInts = s.ptr;
}
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() { () @trusted { free(ints); }(); }
scope ptr() { return ints; }
scope ptr() const { return ints; }
scope ptr() immutable { return ints; }
}
And that compiles just fine. Because the `return` attribute is still inferred.
> It's only if `ptr` is a template this function this bug manifests. There's
> also a bug with `inout`, but that's another issue:
>
> https://issues.dlang.org/show_bug.cgi?id=17927
Yes, that's another issue. The method there doesn't have the `return`
attribute.
Maybe your point is that the `return` attribute shouldn't be inferred? Then
`ptr` wouldn't compile, but you could still make essentially the same mistake
by accessing `s.ints` directly.
> I didn't bother to respond to the rest of your analysis. The crux of the
> problem here is the interaction of a template function with DIP1000 and
> inferred lifetimes, and how it differs from the non-template functions.
My point is that changing the lifetime of `malloc(...)` could maybe fix this
issue and prevent the very similar mistake of copying `s.ints`, while still
allowing the `return` attribute to be inferred.
--
[Issue 18917] Default Value for Function-Type Template Value-Parameter Causes Conflicts in Instantiation
https://issues.dlang.org/show_bug.cgi?id=18917 --- Comment #2 from Vijay Nayar --- Any confirmation on whether this is a legitimate bug or if the intended behavior is that default values for template parameters are meant to be instantiated only once and cause conflicts for future instantiations of the same template? --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #14 from Mike Franklin --- (In reply to Atila Neves from comment #13) > It's only if `ptr` is a template this function this bug manifests I suspect that's due to the undocumented inference rules add by https://github.com/dlang/dmd/pull/8408 Note that in DIP25 it states: "Annotation are deduced for templates and lambdas, but must be explicit for all other declarations". --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #13 from Atila Neves ---
> Apparently, DMD goes with infinite
Only if it's a template this function. As mentioned before, writing out the
explicit instantitations for mutable, const and immutable doesn't compile.
That's the bug. Hence the issue title being "DIP1000 defeated if auto used
instead of scope in variable declaration with template this member function"
instead of "DIP1000 defeated if auto used instead of scope in variable
declaration".
dmd is already doing the right thing with `scope ptr() { return ints; }`,
`scope ptr() const { return ints; }` and `scope ptr() immutable { return ints;
}` even if it's `auto s = MyStruct(10)` instead of `scope s = MyStruct(10)`.
It's only if `ptr` is a template this function this bug manifests. There's also
a bug with `inout`, but that's another issue:
https://issues.dlang.org/show_bug.cgi?id=17927
I didn't bother to respond to the rest of your analysis. The crux of the
problem here is the interaction of a template function with DIP1000 and
inferred lifetimes, and how it differs from the non-template functions.
--
