Instantiation of nested structs should be allowed outside their parent scope

[Timon Gehr]

On 09.11.21 19:41, Stanislav Blinov wrote:
> On Tuesday, 9 November 2021 at 17:18:31 UTC, Timon Gehr wrote:
>> On 09.11.21 17:51, Stanislav Blinov wrote:
>>> On Tuesday, 9 November 2021 at 16:34:26 UTC, Timon Gehr wrote:
>>>
>>>> Sure, which is what I said (do it = copy things). But why would you 
>>>> want the check to behave differently from actual code that copies 
>>>> things?
>>>
>>> ? Because the check only needs to tell me if copying throws or not.
>>
>> For the specific issue we have been discussing, it seems to me that 
>> copying does not work at all, independent of whether it's throwing or 
>> not. It should just work.
> 
> It does work just fine. Can copy NestedThatFails within its context. Can 
> copy it to outside of its context too if need be, with copyEmplace. 
> Before you ask "why not just use copyEmplace for the test then?" the 
> answers are 2:
> 
> 1) it's '@system', so I won't be able to devise an isSafe... test out of 
> it, and

Also, you won't be able to use it in `@safe` code. That's not the same 
as "just work". The compiler should just do this correctly, just like 
copyEmplace.

> 2) look at its source code, the very first static if inside ;)
> 
>>> That specific check, that is. Nothing else. Because that information 
>>> drives how I allocate or how, exactly, do I copy things. Other checks 
>>> drive other things. BTW, I forgot to show one more thing, that is 
>>> that isNothrowCopyable reduces to isCopyable for BetterC. Not Phobos' 
>>> isCopyable, but an isCopyable that tests distinct types because 
>>> qualifier hell. Which should be that same union test from before, 
>>> only without attributes. But, alas, it is not.
>>> ...
>>
>> What's different?
> 
> I don't understand what you're asking. What's different where?
> ...

You said: "should be _that same_ union test [...] it is not". My 
question was what is not the same.

>> Why should the checks be able to do anything that standard code cannot 
>> do? Why should the checks not have access to context when the actual 
>> code will have such access? I think a lot of the trouble you are 
>> having probably comes down to compiler bugs and/or missing reasonable 
>> enhancement requests.
> 
> You've seen the test. It's a lambda outside of unittest. How do you 
> propose to write a trait that DOES have access to context? Same goes for 
> std.range.isInputRange...
> ...

The constraint should have as much access to context as the function 
itself does. E.g., templates are sometimes instantiated locally in the 
caller's context.

> Just to reiterate - I *have* a working implementation of a test that 
> works around this problem for testing copy initialization specifically.

Well, that specific problem comes down to what I think is just a 
compiler bug, I was just suggesting that probably there are other things 
that need to be fixed in the compiler as well.

> I'm just tired of these workarounds.
> ...

As you should be. It's not an acceptable situation.