Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gafter opened this issue Jun 8, 2017 · 18 comments
Open

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

gafter opened this issue Jun 8, 2017 · 18 comments

Comments

@gafter
Copy link
Member

@gafter gafter commented Jun 8, 2017

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

/cc @jaredpar @VSadov @jcouv

@gafter gafter added this to the 7.2 candidate milestone Jun 8, 2017
@gafter
Copy link
Member Author

@gafter gafter commented Aug 3, 2017

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

@gafter gafter changed the title Champion "Span<T>, aka interior pointer, aka stackonly struct" Champion "Span<T>, aka interior pointer, aka stackonly struct" (C# 7.2) Sep 23, 2017
@gulshan
Copy link

@gulshan gulshan commented Oct 23, 2017

The proposal link is broken.

@initram
Copy link

@initram initram commented Oct 23, 2017

@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
Copy link
Member

@jcouv jcouv commented Oct 23, 2017

Fixed link. Thanks @initram

@Nukepayload2
Copy link

@Nukepayload2 Nukepayload2 commented Jun 14, 2018

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
    {
    }
}
@gafter gafter added this to C# 7.2 in Language Version Planning Mar 6, 2019
@tarikguney
Copy link

@tarikguney tarikguney commented Sep 27, 2019

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
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi commented Sep 27, 2019

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
Copy link

@tarikguney tarikguney commented Sep 27, 2019

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
Copy link
Member

@jaredpar jaredpar commented Sep 27, 2019

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
Copy link

@tarikguney tarikguney commented Sep 27, 2019

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
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi commented Sep 27, 2019

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
Copy link
Member

@jaredpar jaredpar commented Sep 27, 2019

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
Copy link

@tarikguney tarikguney commented Sep 27, 2019

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
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi commented Sep 27, 2019

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
Copy link

@tarikguney tarikguney commented Sep 27, 2019

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

Umm. Not agree.

@tarikguney
Copy link

@tarikguney tarikguney commented Sep 27, 2019

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
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi commented Sep 27, 2019

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
Copy link

@tarikguney tarikguney commented Sep 27, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.