Instantiation of nested structs should be allowed outside their parent scope

[Timon Gehr]

On 09.11.21 15:11, Stanislav Blinov wrote:
> On Tuesday, 9 November 2021 at 09:24:29 UTC, Timon Gehr wrote:
>> ...
>>
>> There is never really a need to instantiate a value of any type just 
>> to check what it supports.
> 
> Yes, there is. isInputRange tries, and fails for some nested structs 
> (keyword - some).

Fair, sometimes you want to check whether you can declare a value of the 
given type, though that _should_ fail in case it's not actually possible 
for the algorithm to do that and get an actually working instance. It's 
plausible that that check does not actually work correctly for some 
Phobos functions though, as local instantiation of templates is a bit messy.

> This copy attributes check needs an instance too.
>  >> enum bool isNothrowCopyable(To, From) = __traits(compiles, (To to,
>> From from)nothrow{ to=from; });
> 
> Nope. That tests assignment. Which may, or may not, also test 
> destructor, depending on whether opAssign is defined. The check must 
> needs to test ONLY copy-initialization (blit, copy ctor, and/or postblit).
> ...

I see, I guess you actually want this, but it does not work:

enum bool isNothrowCopyable(To, From) = __traits(compiles, (From 
from)nothrow{ To to=from; });

What's the use case for checking only this kind of initialization, if 
you don't need to create new instances of `to`?