Instantiation of nested structs should be allowed outside their parent scope

[Stanislav Blinov]

On Tuesday, 9 November 2021 at 09:24:29 UTC, Timon Gehr wrote:
> On 08.11.21 02:02, Stanislav Blinov wrote:
>> 
>> If you're not convinced, I encourage you to try and define e.g.
>> 
>> ```d
>> enum bool isNothrowCopyable(To, From) = /* ??? */
>> ```

...WITHOUT REIMPLEMENTING COPY INITIALIZATION BY HAND.

>
>
> 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). 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).

> (Untested. If I have misunderstood what it should check for, 
> just change the function body.)

Yes. "Just". For that specific check - by recreating the copy 
semantics. I can show you the code I came up with, but like I 
said, I really do encourage you to try. Just to experience, in 
full, how ridiculous it gets.