[Issue 17036] Template default parametr does not works correctly

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Jan 4 05:28:33 PST 2017


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

bitter.taste at gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bitter.taste at gmx.com

--- Comment #1 from bitter.taste at gmx.com ---
---
struct S0
{
    void x[1];
}
pragma(msg, S0.init);
---

As you can see this outputs `S0([cast(ubyte)0u]`, let's assume that the
compiler is right and try using that value as initializer

---
auto x = S0([cast(ubyte)0u]; // and I thought you couldn't cast a ubyte into a
void
---

gives a fairly explicative error, which is what one would rightfully expect

---
cannot implicitly convert expression ([cast(ubyte)0u]) of type ubyte[] to
void[1]
---

on the other hand using the `.init` directly works perfectly..isn't that weird
?

---
auto x = S0.init; // works
---

Let's take a step back, where's the initializer coming from? Here it is [1],
you sneaky bastard! So what happens here is that a zero-initialized TypeSArray
is created with a void[1] type bolted on, the trick falls short when the struct
initializer (the aforementioned `S0([cast(ubyte)0u]` that now has a S0(void[1])
type) is run trough dtemplate `matchArg` and trough the CTFE engine where
nothing is done beside losing our bolted-on type.
What happens next is where the error originates, the new initializer gets
trough the semantic phase

---
ArrayLiteralExp::semantic('[cast(ubyte)0u]')
---

if you're familiar with the inner workings I'll also add that `type` is null
right now and the deduced type is `ubyte[]` which is the technically right
answer but the wrong one in this context. ugh.

Here's where the shit hits the fan

---
ArrayLiteralExp::implicitConvTo(this=[cast(ubyte)0u], type=ubyte[], t=void[1])
TypeDArray::implicitConvTo(to = void[1]) this = ubyte[]
---

What to do? One could try not to lose the hacked-up type of the array, relax
the rules for casts to `void[N]`, emit a `void` initializer instead of a
zeroing the array (which is what one would expect since void has no default
initializer), hope for the best, use another lang^Hthat's it!

[1] https://github.com/dlang/dmd/blob/master/src/mtype.d#L5040

--


More information about the Digitalmars-d-bugs mailing list