`noreturn[]` does not contain characters and hence is not subject to
autodecoding. The previous behaviour caused the range primitives (`put`,
...) to call into autodecoding related functions which couldn't handle
`noreturn[]`.
That error caused `isInputRange!(noreturn[])` to yield false.
Alias traits from druntime
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Signed-off-by: Eduard Staniloiu <edi33416@users.noreply.github.com>
Signed-off-by: Razvan Nitu <RazvanN7@users.noreply.github.com>
Merged-on-behalf-of: Razvan Nitu <RazvanN7@users.noreply.github.com>
Make alias templates to core.internal.traits symbolic aliases to avoid extra te…
Signed-off-by: Andrei Alexandrescu <andralex@users.noreply.github.com>
Signed-off-by: Razvan Nitu <RazvanN7@users.noreply.github.com>
Merged-on-behalf-of: unknown
This incidentally fixes a 'TODO' in BuiltinTypeOf: ifloat/idouble/ireal
and cfloat/cdouble/creal were being collapsed to ireal and creal and
their qualifiers were being discarded.
The current implementation relies on issue 21570 to reject enums with
static arrays as their base type.
Use another is-expression instead of `isStaticArray` to detect types
that are (convertible to) static arrays.
See https://issues.dlang.org/show_bug.cgi?id=21570
`isAssignable` would previously return `true` for non-copyable types,
even though code that tried to use an lvalue would not compile.
This behavior was originally found when implementing `-preview=in`.
With the new -preview=in check, the const-folding seemed to be a bit
too aggressive when an rvalue is passed, meaning that the check might
fail (probably due to the code that initialize the temporary).
* std.traits: Use delegates within some __traits(compiles) check to avoid constfold
With the new -preview=in check, the const-folding seems to be a bit
too aggressive when an rvalue is passed, meaning that the check might
fail (probably due to the code that initialize the temporary).
To avoid this issue, we simply wrap the assignment in a lambda that
will not be called, as there is no downside to that change.
* std.traits: Adapt unittest to pass with `-preview=in`
For a long time, the 'in' storage class was only a second class citizen,
merely an alias for 'const', which is a type constructor.
While it was also documented for a long time as being 'scope',
this was removed when 'scope' actually started to have an effect
(when DIP1000 started to be implemented).
Currently, a switch (-preview=in) allows to get back this 'scope'.
However, the 'in' storage class does not really exists,
it gets lowered to 'const [scope]' at an early stage by the compiler,
which means that we expose what is essentially an implementation
detail to the user.
There is a PR in DMD (dlang/dmd#11474) that aims to give 'in' an actual
identity, instead of it being lowered to 'const [scope]'.
The underlying motivation is to allow for extending 'in''s functionality,
giving it the ability to pass by 'ref' when necessary, and accept rvalues.
However, regardless of the second goal, having proper support for 'in'
would lead to less confusing messages, better code generation,
and less confusion w.r.t. the behavior of `std.traits.ParameterStorageClass`.
