* reduce: Document Acc, Elem order in most visible place
* Reduce doesn't enforce predicates
* Reduce: Document behaviour on range with 1 elem
* Doc: Remove references to implemententation detail
Accumulator is the commonly used term for this concept.
* Fix#9585 Add check `variant` alignment
There has been code that handles alignment for a long time
now, and while this module is unlikely to be touched anymore, create a
regression test so the issue can be closed.
* Apparently double is 32bit aligned on x86
The current contraints have been implemented in #3837 to make `each`
behave more like `foreach` and automatically destructure tuples.
I haven't publically documented this behavior because it is probably
better these days to use `bind` for that.
This ports the fixes from abs(T)(ComplexT) regarding NaN and skipping
potentially inaccuracy inducing mathematical no-ops when one arg is 0 to
hypot. Both functions do the same thing and should be deduplicated.
hypot also has some logic regarding under and overflows, and while I
don't fully understand it, it should probably not be removed for complex
numbers.
Strictly speaking, the Kelvin scale is not measured in degrees, so the
previous name was incorrect. Changing it in all cases preserves
consistency.
Fixes#10540
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
