just return the value and assign it to the receiver. Renamed the
conversion function and also cleaned up all the `typeof` calls, which
were very verbose.
This is a simple and straightforward trait. It just says whether the
template argument is a type or not. It has the same functionality as the
trait with the same name in std.traits. However, the implementation is
different. The std.traits version just has an alias overload and uses an
is expression, whereas it seemed like it would probably be more
efficient to split the trait into two and have the kind of argument
determine the result, since the compiler has to go through the work of
deciding whether the argument matches already, though I don't know
enough about the compiler implementation to know for sure that this
implementation is better. Either way, it can be changed later if it's
determined that the std.traits implementation is better.
Now, member structs won't become const due to transitiveness and the
code in `std.format` can choose (erroneously) non-cost toString()
functions of member structs.
An expert has to decide whether this is worth the breaking change. Now,
code that uses `const` tuples and calls toString directly on them will
break. Alternatively, we could use
[Template this parameters](https://dlang.org/spec/template.html#template_this_parameter).
That way, we get a template parameter with the real type of this. Then we can
cast away constness of `this` when we now for certain that it isn't,
since `is(T != typeof(this))` (where T is the template this parameter).
Of course, this implies making toString `@trusted` too.
This might also lead to unforeseen bugs when `const` is cast away but
the member objects are actually const. I'm not sure how this works.
Fwiw, currently std.format and `std.conv: to` already intercepts const tuples,
thus it at least won't call toString directly. The breaking change will
only effect code that calls toString on const tuples directly.
That's why I have added non-prescritive tests. If something in
std.format changes, they'll be alerted and can then decide whether to
change the tests or whether this module also needs work, in case this
would lead a bigger breaking change.
Followup to #10645.
* Use formattedWrite instead of format
* Remove workaround for shared objects in formattedWrite
The tests are still working. Is it safe to assume that the workaround
would've only been merged if there is a test-case checking it?
* Remove sharedToString workaround
For shared classes, it prints the mangled name, for struct pointers it will
print the adress.
This version of Tuple.toString won't work anymore in @safe code in
general if the tuple contains anything descended from Object. I think
this is correct even if a breaking change, since dealing with this issue
should be the responsibility of the caller.
* Comment to existing code
* Reference the bug that a unit test exemplifies
The constructor of the result of std.range.chain copies it's input tuple
and then has to check which of the input-ranges in the first non-empty
one. The member function empty is not guaranteed to be const, filter is
probably the most prominent function that has to be "primed". On the
first call to empty(), filter will try to advance all it's input ranges
to the first element that matches the predicate.
For ranges with full value semantics, using the old input object instead
of the new internal buffer means that the work of priming is done twice.
If any ranges have reference semantics, the references gets advances,
but the value-semantic parts of the range-composition gets reset.
This fixes#10561 and #9877
It does the same thing as the std.traits version. They both alias the
one in druntime. However, the documentaton and tests have been beefed up
a bit.
I also added assertWithQualifiers as a private test helper, which it may
make sense to add later as a public test helper somewhere, but we don't
currently have any module or package for that sort of thing, so for now,
it's private. Some of the existing tests should probably also be
refactored to use it, but I'm not worrying about that as part of these
changes.
Previously, code that already knew the desired index was forced to
compute a type to pass to get!T or memberName!T, just for get!T or
memberName!T to turn that type back into an index. Removing this
unnecessary round trip simplifies the code.
Additionally, since memberName is no longer dependent on SumType.Types,
it can be moved to module scope, and its instantiations can be shared
across different SumType instances.
* Fix#10538 - Cannot swap a std.typecons.Tuple
Co-authored-by: Elias Batek <0xEAB@users.noreply.github.com>
* De-optimize `opAssign` of `std.typecons.Tuple`
---------
Co-authored-by: Elias Batek <0xEAB@users.noreply.github.com>
Co-authored-by: Elias Batek <desisma@heidel.beer>
