Make permutations into forward range.
Signed-off-by: Razvan Nitu <RazvanN7@users.noreply.github.com>
Signed-off-by: H. S. Teoh <quickfur@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Previously, a TOCTOU bug in threadInfo could result in a null
dereference if 'scheduler' was changed to null between the evaluation of
the 'if' condition and the call to scheduler.threadInfo.
Fix issue 16034: map should be possible with a reference only
Signed-off-by: Paul Backus <snarwin@gmail.com>
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Since they do not present the same structural interface, they should be
separate types (i.e., hasMember cannot tell the difference between a
'shared' method and a thread-local method).
SharedRegion will now always assume that its ParentAllocator is a real
allocator, and attempt to use its 'allocate' and 'deallocate' methods
accordingly.
The behavior previously provided by SharedRegion!(NullAllocator, ...)
remains available via shared(BorrowedRegion!(...)).
See issue 23090 for detailed rationale.
Region will now always assume that its ParentAllocator is a real
allocator, and attempt to use its 'allocate' and 'deallocate' methods
accordingly.
The behavior previously provided by Region!(NullAllocator, ...) remains
available via BorrowedRegion!(...).
See issue 23090 for detailed rationale.
Previously, this behavior could only be obtained by instantiating Region
with NullAllocator as its ParentAllocator. Extracting it into a separate
allocator will allow Region itself to be simplified.
According to earlier versions of the language spec, checking the
invariant of a struct would also cause its fields' invariants to be
checked, recursively. SumType's invariant was added to make SumType
behave consistently with other structs in this regard.
The spec, however, was wrong: invariants of struct fields are not
checked unless the field is accessed directly, and never have been.
Thus, to make SumType behave consistently with other structs, its
invariant must be removed.
This change should not break any valid programs, since code that relies
on the failure of an invariant has undefined behavior per the spec.
Spec correction PR: https://github.com/dlang/dlang.org/pull/3405
