In an attempt make it so that non-copyable types worked with some of the
functions in std/range/package.d, they were made to use moves instead of
assignment, which broke the code for types which work with assignment
but not moves (which affected the folks at Weka).
The code checked for assignment but not whether move could be used, and
that didn't change when the code was changed to use move, meaning that
the checks didn't match what the code was actually doing.
So, to support both the non-copyable types and the ones that can be
assigned to but not moved to, this changes the code to use
core.lifetime.forward which will move the argument if it can and assign
otherwise. So ,the code that worked previously should work again, and
the newer functionality of being able to use non-copyable types with
this code should continue to work.
Discussion here: https://github.com/dlang/phobos/pull/8721
std.process.Config.preExecDelegate is just like
std.process.Config.preExecFunction, but can capture an environment, for
example:
import core.sys.linux.sys.prctl : PR_SET_PDEATHSIG, prctl;
import std.process : Config, execute;
void runProgram(int pdeathsig)
{
execute(
["program"],
config: Config(
preExecDelegate: () @trusted =>
prctl(PR_SET_PDEATHSIG, pdeathsig, 0, 0, 0) != -1,
),
);
}
preExecFunction is retained for backwards compatibility. If both
preExecFunction and preExecDelegate are given, both are called.
std.process.Config.preExecFunction is now a delegate instead of a function
pointer, and can therefore capture an environment, for example:
import core.sys.linux.sys.prctl : PR_SET_PDEATHSIG, prctl;
import std.process : Config, execute;
void runProgram(int pdeathsig)
{
execute(
["program"],
config: Config(
preExecFunction: () @trusted =>
prctl(PR_SET_PDEATHSIG, pdeathsig, 0, 0, 0) != -1,
),
);
}
Despite function pointers implicitly converting to delegates, this is a
backwards-incompatible change, as user code may rely on the field being a
function pointer. For example, code like the following will no longer compile:
import std.process : Config;
nothrow pure @nogc @safe
bool f() { return true; }
void example()
{
auto config = Config(preExecFunction: &f);
bool function() g = config.preExecFunction;
}
FieldNames is roughly equivalent to std.traits' FieldNameTuple, and
FieldTypes is roughly equivalent to std.traits' Fields (which used to be
FieldTypeTuple).
The primary difference implementation-wise is that the phobos.sys.traits
versions require that the types that they're given be aggregate types.
For some reason, the std.traits versions accept any type and then try to
give a result that at least sort of make sense when they're given a type
which isn't an aggregate type (even though they really can't, because a
type which isn't an aggregate type has no fields, making any choice kind
of arbitrary).
For types which aren't aggregate types, Fields gives the type back in an
AliasSeq, and FieldNameTuple gives AliasSeq!"". Neither makes any sense
to me. I assume that it was done so that those traits could be used in
generic code and work with any type, but realistically, if you want to
do anything sane with them, you need to already have verified that
you're dealing with an aggregate type, since it's just going to be
error-prone to do stuff like Fields!int and then get AliasSeq!int back
as if it had a single field of type int (or FieldNameTuple!int and get
an empty string as the name). So, the phobos.sys.traits versions simply
require that you give them aggregate types to avoid that entire mess.
FieldNames evaluates to the names of the fields as strings. The "Tuple"
in the name of the std.traits version is an artifact from when AliasSeqs
were called TypeTuples, so I didn't keep that.
FieldTypes evaluates to the types for the fields. It's FieldTypes rather
than Fields for clarity, since it's not at all obvious what Fields is
supposed to give you (if I'd had to guess, I would have guessed the
symbols, not the types).
FieldSymbols is new. Its usefulness is questionable, since it does
almost exactly the same thing that tupleof does. However, I've included
it because of the subtle issues that you get with nested structs -
namely that tupleof includes a context pointer in its result, which you
probably don't want (though that obviously depends on what you're
doing), and FieldNames and FieldTypes don't include it (just like their
std.traits counterparts don't), so it seemed like it would make it less
error-prone to have FieldSymbols for the cases where symbols are needed.
The documentation explains (and the examples show) the difference
between FieldSymbols and tupleof so that the programmer can decide which
makes more sense for their particular use case.
Fix broken links in std.range.chain
Signed-off-by: Dennis <dkorpel@users.noreply.github.com>
Merged-on-behalf-of: Jonathan M Davis <jmdavis@users.noreply.github.com>
isAggregateType is the same as isAggregateType from std.traits but with
tweaked documentation and examples.
isInstantiationOf is the equivalent of std.traits' isInstanceOf. The
documentation and tests have been updated, and an overload for partial
instantiation has been added.
The reason for the name change is that "instance" is not normally used
with templates (instantiation is typically considered to be the correct
term). Rather, instance is normally used to indicate that a value is an
instance of a particular type. So, using isInstanceOf to check whether a
type is an instantiation of a particular template seems like a misuse of
the term and like it could easily cause confusion. The downside of
course is that the new name is longer and harder to type, but while it's
a trait that is necessary in some situations, IMHO, it's not needed
frequently enough for the longer name to be a problem - particularly
when it's a clearer name.
I did try to simplify isInstantationOf's implementation so that it
didn't need an alias overload, but I failed, because apparently, when
typeof is used on the instantiation of a function template, the fact
that it's a template instantation is lost. So, unfortunately, we're
forced to operate on the function's symbol rather than its type to
detect whether it's an instantation of a particular template. The
documentation has been updated to include that information.
I also tried to then make the alias overload not need a helper template
so that fewer template instantiations would be needed, but that didn't
work either, because the alias overload needs a template specialization
to work, and I couldn't find a way to write an is expression that would
have the same effect. So maybe, someone can improve the implementation
later if they can figure that out, but since it's the same
implementation as std.traits, we're not any worse off. And the overload
which operates on aggregate types probably sees a lot more use anyway.
They're each the same as their std.traits counterparts, though the
documentation and tests have been updated.
I considered renaming KeyType and ValueType to AAKeyType and AAValueType
for increased clarity, but that seems pretty ugly, and while "value
type" could mean other things depending on the context, I don't know
what else it could mean in this context. So, I left the names the same.
These correspond to templateAnd, templateNot, and templateOr from
std.meta. The names have been shortened and made PascalCase to make them
consistent with our normal naming rules. It's PascalCase rather than
camelCase, because the result is a template rather than a value, and we
don't normally prefix symbols with "template" just because they're
templates.
The implementation of Not is unchanged. However, unlike their std.meta
counterparts, And and Or do not short-circuit their evaluation. This makes
them consistent with the rest of phobos.sys.meta (whereas std.meta is
inconsistent about whether its templates short-circuit their evaluation),
but it's also because they're implemented to be iterative rather than
recursive, which should make them more efficient.
Since the compiler is treating the auto-generated copy-constructor for
OnlyResult as private (thus rendering it useless outside of
std.range.package), this commit adds an explicit one and makes it
public. Once the dmd bug has been fixed, the explicit copy constructor
should be removed.
This appears to be the check which is making
https://github.com/dlang/phobos/pull/8924 fail the style check with
warnings such as
std/internal/test/range.d(43:14)[warn]: Variable b is never modified and could have been declared const or immutable.
It makes no sense to require that unit tests follow such a rule, and it
is actually detrimental when tests involve stuff like copy constructors,
because then the type of the target variable matters as part of the
test.
Honestly, I think that it should probably not be checked at all, since
it's a pretty questionable requirement in many cases given how strict
D's const and immutable are, but that's more debatable, whereas this
check really makes no sense with unit tests, so I'm just disabling it
for unit tests for now. We can disable it more generally later if it
turns out that it's causing problems for normal code.
This also makes it so that isImplicitlyConvertible and
isQualifierConvertible in phobos.sys.traits can be partially
instantiated, since I missed that before.
Instantiate is basically identical to the one in std.meta
implementation-wise, but the documentation and unit tests have been
improved.
ApplyLeft and ApplyRight should be functionally the same as their
std.meta counterparts, but they have a simpler implementation than their
std.meta counterparts (I'm pretty sure that the extra complexity in the
old implementation is to work around built-in types not working with
aliases, which was fixed a while ago). Of course, their documentation
and tests have also been improved.
These are straight from std.traits but with improvements to the
documentation and unit tests.
The __InoutWorkaroundStruct bit is kind of ugly, but it does seem to be
necessary due to how inout works.
EnumMembers is obviously needed and does the same thing as its
std.traits counterpart.
isEqual is new, and it really shouldn't be used in many circumstances,
but it's needed in conjunction with Unique to be able to do what
NoDuplicates from std.meta does when given an AliasSeq of enum members.
So, if you need the list of enum members to have no duplicate values
(e.g. when creating a final switch), then you would now do
Unique!(isEqual, EnumMembers!E) instead of NoDuplicates!(EnumMembers!E).
As part of isEqual's documentation, I added a list of examples which
highlight the difference between operating on the list of enum members
as an AliasSeq and operating on them as a dynamic array, since that's
not something that's at all obvious - and it shows why you might need to
use isEqual with Unique to weed out duplicate values instead of doing
something like [EnumMembers!E].sort().unique() to weed them out. For
documentation purposes, I just assumed that uniq would be renamed to
unique, but the documentation can be fixed later if need be once we have
the actual functions in Phobos v3.
If there's a constructor that looks like a copy constructor except that
it takes an rvalue instead of taking the argument by ref, then that type
can't have a copy constructor, and one of Tuple's constructors was
causing that problem. So, this fixes it so that it doesn't.
Stride is basically the same as std.meta's Stride aside from some
improvements to the tests and documentation.
Unique is the equivalent of std.meta's NoDuplicates except that it's been
updated in the same fashion as indexOf. So, instead of checking for
whether the elements are "the same" based on some complicated rules,
Unique takes a predicate which it uses to compare the elements for
equality (essentially making it the AliasSeq equivalent of
std.algorithm's uniq, though uniq requires that the range be sorted, and
Unique has no such requirement). So, the programmer can decide what kind
of comparison is used.
