Instantiation of nested structs should be allowed outside their parent scope

[Timon Gehr]

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.

> 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?

> For nested structs, such checks need to do things outside of context - 
> that's why they MAY behave differently from actual code. Compiler 
> doesn't like that. I think it shouldn't not like that.

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.