Open gafter opened 7 years ago
A draft of more precise span safety rules is at https://gist.github.com/gafter/20aee8cfac801caebd19b49af180f708
The proposal link is broken.
@gulshan The correct link is https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/span-safety.md
The proposal was moved to the csharp-7.2 folder
Fixed link. Thanks @initram
Are ref struct
s CLS-Compliant? The following code is legal in Visual Studio 15.7.2, but StackOnlyType
obviously depends on a c#-only language feature.
using System;
[assembly:CLSCompliant(true)]
namespace MyLibrary
{
[CLSCompliant(true)]
[Obsolete("Types with embedded references are not supported in this version of your compiler.", false)]
public ref struct StackOnlyType
{
}
}
Not sure if this topic is active and any C# designer pays attention to this but I have asked about the reason why ref struct
are the chosen keywords rather than something else like stackonly struct
, here and https://softwareengineering.stackexchange.com/questions/398954/why-did-c-choose-ref-for-ref-struct
And I even liked stackalloc struct
suggested by Eric Lippert better. Could we get some explanation, please?
but I have asked about the reason why
ref struct
are the chosen keywords
Because it was pretty simple and we didn't think it warranted any other syntax. No one felt particularly stronly, so we went with this.
but I have asked about the reason why
ref struct
are the chosen keywordsBecause it was pretty simple and we didn't think it warranted any other syntax. No one felt particularly stronly, so we went with this.
But, do you think it represents the meaning of ref struct
s? For Span<T>
, I would understand it, but for more general use of ref struct
, does ref
explain its limitations?
While stackalloc
is probably the most evangelized usage of ref struct
at it's core this feature is all about ref
values, their limitations and making them more usable in the language and runtime. You can look at the span safety doc to see a more detailed explanation of why ref-ness is at the core of this feature, not stackalloc
.
This is going to be even more true if we end up taking proposals like allowing fields to have a ref
modifier. That will only be possible in ref struct
values for the same reasons a ref struct
can only be a field of another ref struct
.
Basically this feature is all about ref-ness hence ref struct
is a fairly representative name. Also adding new contextual keywords to the language always starts at -100 which is another reason against stackonly
.
BTW: if you want to blame a person for ref struct
I'm probably the best choice. The name comes from our experiments in Midori but the reason for calling it ref struct
there matches with reasoning for doing it in .NET.
While
stackalloc
is probably the most evangelized usage ofref struct
at it's core this feature is all aboutref
values, their limitations and making them more usable in the language and runtime. You can look at the span safety doc to see a more detailed explanation of why ref-ness is at the core of this feature, notstackalloc
.This is going to be even more true if we end up taking proposals like allowing fields to have a
ref
modifier. That will only be possible inref struct
values for the same reasons aref struct
can only be a field of anotherref struct
.Basically this feature is all about ref-ness hence
ref struct
is a fairly representative name. Also adding new contextual keywords to the language always starts at -100 which is another reason againststackonly
.BTW: if you want to blame a person for
ref struct
I'm probably the best choice. The name comes from our experiments in Midori but the reason for calling itref struct
there matches with reasoning for doing it in .NET.
Thanks @jaredpar for taking time to reply. When I read that document you shared, I see that ref
makes sense for the variables or return values, etc. but when it comes to the decorating the struct
, it looks like it is an unnecessary leak from the fact that this types structs can be safely used with ref
variables onto the struct
definition itself. The stackonly
nature of it enabled the safe ref-ness
of these type of structs, and it sounds like calling it ref struct
is like calling cement a wall, hence limiting the future purposes of this struct
to a wall only.
I would understand it, but for more general use of ref struct, does ref explain its limitations?
In the same way that the term struct
itself explains its limitations. It's a modifier you need to go read up on to figure out what it means. It's an extremely advanced construct for very specialized circumstances. I'm not really concerned about if ref
is the best modifier or not for this purpose.
But, do you think it represents the meaning of ref structs?
Yes...? :)
hence limiting the future purposes of this struct to a wall only.
I'm not certain how it's limited. Could you give an example? There are already many avenues being explored to enhance ref-structs in the future. Are there avenues that you think should be explored, but can't be because of the choice of this token?
hence limiting the future purposes of this struct to a wall only.
Disagree. I'm not sure how the choice of ref
as a token in any way limits this feature. Likewise I'm not sure how calling it stackonly
would magically open up new possibilities for the implementation.
It's a word, it doesn't change the semantics.
While I was typing my answer to @CyrusNajmabadi (which I deleted later), I realized something which we didn't discuss and that is ref
keyword only used for data (value or reference) stored in stack. It seems your view on ref struct
comes from this existing usage of ref
in the first place with variables, parameters ,etc. So, you guys may have wanted to keep this behavior the same with the struct
s themselves, applying the existing pre-conditions of stack-only-ness of ref
from the pre-7.2 time. However, it makes sense when working with variables or parameters since you know they are stored in the stack (either as values or references) but this does not apply in the same way to structs, because structs can be stored in heap, as well.
Now you are combining the stack only characteristic that come from the nature of variables and parameters into ref
and applying it to the struct
. But ref
is a workaround to refer memory addresses in the stack, and by itself, it has nothing to do with the stack-only-ness.
Now you are combining the stack only characteristic that come from the nature of variables and parameters into ref and applying it to the struct. But ref is a workaround to refer memory addresses in the stack, and by itself, it has nothing to do with the stack-only-ness.
@tarikguney if you'd like to discuss this topic more, there are appropriate avenues (like gitter.im or discord). You're talking about something (the syntax choice here) that was already decided on years ago and which isn't going to change. It's unclear what hte benefit of the discussion is. You asked why it was done this way, and it was answered. Is there something else you need to know at this point?
It's a word, it doesn't change the semantics.
Umm. Not agree.
Now you are combining the stack only characteristic that come from the nature of variables and parameters into ref and applying it to the struct. But ref is a workaround to refer memory addresses in the stack, and by itself, it has nothing to do with the stack-only-ness.
@tarikguney if you'd like to discuss this topic more, there are appropriate avenues (like gitter.im or discord). You're talking about something (the syntax choice here) that was already decided on years ago and which isn't going to change. It's unclear what hte benefit of the discussion is. You asked why it was done this way, and it was answered. Is there something else you need to know at this point?
No worries. I got my answer. I wish I was there at the time. Thanks for your time!
Umm. Not agree.
It literally doesn't. :)
Regardless of the token we chose (which could have been ref
, stackalloc
wibblywobblytimeywimey
we can choose what semantics we want it to have.
ref
was reasonable enough and doesn't seem to have anything inherent in it that would limit us in the future. Indeed, as i mentioned there are many ways we're looking at expanding on what ref-structs are capable of.
Umm. Not agree.
It literally doesn't. :)
Next time, I will call an apple "pear" when I am asked what my favorite fruit is. I am sure people will understand :))
Anyways, thanks for the responses.
/cc @jaredpar @VSadov @jcouv