4 ms·
It seems that it will CLR-enforced so I would guess that it's not going to be available for any type: The fast representation makes the type automatically st
by zastrowm 10y ago
It seems that it will CLR-enforced so I would guess that it's not going to be available for any type:
The fast representation makes the type automatically stack-only, i.e. the constraint
will be enforced by CLR type loader. This restriction should also be enforced by
managed language compilers and/or analyzers for better developer experience. For
the slow span, language compiler checks and/or analyzers is the only option (as
the runtimes won't enforce the stack-only restriction).
- Locke1689 10y agoRight, ultimately it will be enforced by the CLR type system, much the way most types are in .NET, but practically it will be enforced by the compiler. You can already see this in the "ref parameters" feature in C# today: they can be parameters to methods but cannot be stored in fields. This implies that they can only exist on the stack. Similarly, when we add support for ref-locals and ref-returns in C# 7 that will still disallow ref fields, so ref variables will still only be allowed on the stack.