The template `canMatch` does not account for `ref`.
The template `valueTypes` stores all types of the member values and uses SumTypes's `get` function, which returns a `ref`.
However, ref does not persist and the type is not sent to `canMatch` as a `ref`.
Because of this, when matching, `canMatch` will fail as it will test for a copy, and returning a reference of that value results in escaping it.
Fix Issue 23101
Signed-off-by: João Lourenço <jlourenco5691@gmail.com>
The template constraint is needed to ensure that the inout constructor
overload is only considered when it is an exact match, without qualifier
conversions.
Without the constraint, a constructor call such as
const(SumType!(int[]))([1, 2, 3])
...would be ambiguous, since it would match both the const constructor
overload and the inout constructor overload at the "match with qualifier
conversion" level.
Previously, SumType incorrectly assumed that all members of an
inout(SumType) must themselves be inout-qualified. However, this is not
the case when one of those member types is declared as immutable, since
the qualifier combination `immutable inout` collapses to just
`immutable`.
Attempting to copy an immutable member type as though it were inout
caused matching to fail in SumType's copy constructor, due to the
following (gagged) error:
Error: `inout` on `return` means `inout` must be on a parameter as
well for `pure nothrow @nogc @safe inout(Storage)(ref immutable(Value)
value)`
Previously, the assignment of the local variable 'newStorage' to the
longer-lived member variable 'storage' caused scope inference to
(correctly) fail.
newStorage was necessary to work around issues 21229 and 22118. Since
those issues have been fixed, newStorage can be safely removed.
Previously, SumType would define the wrong set of constructors for types
whose copyability varies depending on their mutability--a situation that
was impossible with postblits, but is now possible with copy
constructors.
