[std.algorithm.searching] Add extrema to compute min and max
Signed-off-by: Adam Wilson <LightBender@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
* refactor(formattedRead): add not is type validation to template argument 'fmt'
Signed-off-by: João Lourenço <jlourenco5691@gmail.com>
* feat(formattedRead): add overloads to return a tuple with the read values
Signed-off-by: João Lourenço <jlourenco5691@gmail.com>
* test(formattedRead): add unnittests for the tuple return type overloads
Signed-off-by: João Lourenço <jlourenco5691@gmail.com>
* chore(changelog): add a changelog formattedRead entry
Signed-off-by: João Lourenço <jlourenco5691@gmail.com>
---------
Signed-off-by: João Lourenço <jlourenco5691@gmail.com>
In many cases, even when using Unqualified makes sense (as opposed to
Unconst or Unshared), using is(immutable T == immutable U) works just as
well and avoids instantiating any additional templates. This seems to
becoming more known in the D community over time, but it seems
appropriate to mention it in Unqualified's documentation so that more
people will be made aware.
Also, I changed it so that Unqualified is always a wrapper template
instead of directly being an alias of Unqual in core.internal.traits.
This is because the names don't match, and the alias will show up in any
error messages. Long term, we would ideally rename the symbol in
core.internal (potentially turning the std.traits versions into a
wrapper templates instead of an alias). However, since the functionality
is effectively the same, and the std.traits one is the one currently
being used by code in general, it seems better to let the std.traits one
be the alias for now. The same applies to a few traits which are
implemented in core.internal.traits and imported in std.traits or
phobos.sys.traits.
These are the Phobos v3 equivalents of std.traits' hasElaborateAssign,
hasElaborateCopyConstructor, and hasElaborateDestructor. After some
discussion with Adam Wilson, I went with "Complex" rather than
"Elaborate" with the idea that it would be easier to understand for
non-native English speakers. It's also shorter, which is a plus. I also
tried to make the names more consistent (and avoided having
"CopyConstructor" in the name, because it also deals with the postblit
constructor).
For the moment, I have not created hasComplexMoving to check for move
constructors, since that situation has yet to be finalized in the
language. I was surprised to find out that hasElaborateMove was even a
thing, since it was my understanding that opPostMove had never actually
been implemented, so I don't know if we're going to have to worry about
that at all, but either way, it seemed best to leave the question of a
trait for moving until later given that that situation is still in limbo
(even if it does look like the new compiler implementation is well
along).
This makes it so that enums whose base type is an aggregate type are
also considered an aggregate type. It probably doesn't affect much code,
since isAggregateType isn't needed often, and it's fairly rare to
declare enums whose base type is an aggregate type, but in general, code
that cares whether a type is an aggregate type is going to care that an
enum's base type is an aggregate type.
The std.traits version does not take enums into account (and prior to
this commit, neither does the phobos.sys version), but upon reflection,
it seems like it's just likely to cause bugs if it doesn't take enums
into account. Granted, enums whose base type is an aggregate type don't
seem to be very common, but as a result of that, code that tests for
aggregate types likely won't take them into account in the vast majority
of cases, and I see no reason to not have the trait just deal with it
rather than hoping that the user of the trait realizes that it's a
potential issue, in which case, they would need to explicitly use
OriginalType themselves to make it work for enums.
In addition, this way, OriginalType doesn't even get instantiated unless
the type is actually an enum, whereas the correct solution that would
most likely be used otherwise would be to just always do
isAggregateType!(OriginalType!T) instead of isAggregateType!T.
I also put a ddoc comment on the unittest block, since I apparently
missed it previously.
Merge stable
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
The issue also mentions the Druntime bindings, which have been added a few years ago,
however this was missing from std.socket. This implementation provides SO_REUSEPORT on
Windows as well, despite it being equivalent to SO_REUSEADDR, to simplify client code.
Co-authored-by: Elias Batek <desisma@heidel.beer>
