You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please add a way to get warnings for situations in which the compiler would or does produce a defensive copy for a struct type that has some particular new attribute on it. This should be under control of a warning wave (i.e. the warning is off by default so as to reduce compatibility issues*).
*the compatibility concern is that code that uses the attribute and for which there is a defensive copy produces no diagnostic in an older version of the compiler, but does produce a diagnostic in a new version of the compiler.
The text was updated successfully, but these errors were encountered:
🎉 This would likely help with the work in #26321. Conceptually, this is an attempt to implement a lightweight std::unique_ptr<T>, but it's difficult without having an equivalent to boost::noncopyable.
Non-copyable is unrelated to pinned/fixed (a pinned value may or may not be copied, and a non-copyable value may or may not be pinned).
If a non-copyable value is moved from one location in memory to another location in memory, the source location is treated as not-definitely-assigned.
Boxing a value type counts as moving the value from its location on the stack to another location on the heap.
Once boxed, a value cannot be moved back to the stack (unless it's known that there are no other references to the box, optionally). The value is still usable by reference using Unsafe.Unbox<T>.
A reference to a non-copyable value, including the this reference appearing in instance methods of the type, cannot be assumed to reference a non-boxed value. As such, this value cannot be moved.
See item 1 from dotnet/csharplang#1502.
Please add a way to get warnings for situations in which the compiler would or does produce a defensive copy for a struct type that has some particular new attribute on it. This should be under control of a warning wave (i.e. the warning is off by default so as to reduce compatibility issues*).
*the compatibility concern is that code that uses the attribute and for which there is a defensive copy produces no diagnostic in an older version of the compiler, but does produce a diagnostic in a new version of the compiler.
The text was updated successfully, but these errors were encountered: