Champion "Span<T>, aka interior pointer, aka stackonly struct" (C# 7.2)

[gafter]

• Proposal added
• Discussed in LDM (2016-11-01)
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

/cc @jaredpar @VSadov @jcouv

[gafter]

A draft of more precise span safety rules is at https://gist.github.com/gafter/20aee8cfac801caebd19b49af180f708

[gulshan]

The proposal link is broken.

[initram]

@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

[jcouv]

Fixed link. Thanks @initram

[Nukepayload2]

Are ref structs 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
    {
    }
}

[tarikguney]

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?

[CyrusNajmabadi]

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.

[tarikguney]

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, do you think it represents the meaning of ref structs? For Span<T>, I would understand it, but for more general use of ref struct, does ref explain its limitations?

[jaredpar]

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.

[tarikguney]

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.

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.

[CyrusNajmabadi]

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?

[jaredpar]

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.

[tarikguney]

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 structs 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.

[CyrusNajmabadi]

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?

[tarikguney]

It's a word, it doesn't change the semantics.

Umm. Not agree.

[tarikguney]

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!

[CyrusNajmabadi]

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.

[tarikguney]

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.