This should make it so that a variable of type Nullable!T has the same
behavior with regards to destruction as a variable of type T even when
it's const, immutable, or shared.
Generally, if a type has a default value, it should be safe to assume
that it's OK to call the destructor on a default-initialized variable.
The converse is not compatible with `move`, and goes against
implementing non-copyable types.
Rebindable2 is a simplified version of std.typecons.Rebindable that clears up every special case: classes, arrays and structs now have the same struct.
Whichever type you instantiate `Rebindable2` with, you always get the same type out by calling `value.get` on the resulting container.
Also use this type to simplify the parts of Phobos we previously used `Rebindable` for.
* typecons: fix use-after-scope bug in RefCounted unittest
The access through `p` to `rc1` outside the scope of `rc1` is undefined behavior. We have to artificially end the scope of `rc1` and `rc2`, such that within the same scope we can check that the destructor calls do the correct thing of nulling the `_store`.
* fixup
* fixup
Also expose 'parent' when it's abstract
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Copy ctors are still buggy, so unconditionally adding one for Nullable
is everything but a non-breaking change (and was added in the 2.098.1
point release).
One of the `unittest`'s has been modified to also check that
a `File` object managed via `RefCounted!File` handles is deleted
when its last handle is destroyed;
Previously, when recursing into a type's template arguments,
ReplaceTypeUnless would mistakenly attempt to evaluate a template alias
parameter as an expression. In cases where the alias parameter was not a
valid expression or could not be evaluated at compile time, this caused
a compilation failure; in other cases, it caused ReplaceTypeUnless to
give an incorrect result.
This change makes ReplaceTypeUnless correctly treat template alias
parameters as aliases.
While glancing over the Tuple template, I've noticed that it uses the
anti-pattern of nested template declarations *not* depending on the
outer Tuple template parameters.
