Make snippets with Span<T> interactive

[pkulikov]

The snippet code runs successfully in try.dot.net; it hasn't before. I assume that means snippets in docs can be interactive again.

[rpetrusha]

It would be really good to make these two examples interactive. But I'm still not able to run them successfully from the topic, @pkulikov, although I am able to run them directly in try.dot.net. @LadyNaggaga, do you have any sense of why that might be?

[pkulikov]

@rpetrusha indeed, that's a good catch. Thank you.

Page under consideration:
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/foreach-in

@LadyNaggaga when I run the following code

Span<int> numbers = new int[] { 3, 14, 15, 92, 6 };
foreach (int number in numbers)
{
    Console.Write($"{number} ");
}
Console.WriteLine();

in the first interactive block of the page (just replaced all the code with the one above), the error messages are the following:

(1,1): error CS8345: Field or auto-implemented property cannot be of type 'Span<int>' unless it is an instance member of a ref struct.
(2,1): error CS8344: foreach statement cannot operate on enumerators of type 'Span<int>.Enumerator' in async or iterator methods because 'Span<int>.Enumerator' is a ref struct.

Should we create another issue to track this?

[pkulikov]

@rpetrusha @BillWagner what do you think of the following workaround:

public class Program
{
  public static void Main()
  {
      Span<int> numbers = new int[] { 3, 14, 15, 92, 6 };
      foreach (int number in numbers)
      {
          Console.Write($"{number} ");
      }
  }
}

Such snippet runs interactively in docs. If that's a solution for now, I'll updated the code in the samples repo.

Pros:

• Examples with Span<T> are interactive

Cons:

• Too much "noise" of the Program/Main declaration for simple snippets. That also makes such snippets not consistent with others.

@LadyNaggaga if Program/Main are absent, are they generated? And if generated, then Main is async?

[svick]

@pkulikov As I understand it, Try.Net by default uses C# scripting. And within scripts, top-level variables are treated as fields, which explains CS8345. Also, you can use await in scripts, which I think means they have to be treated as async methods, which explains CS8344.

I think a good way to handle this would be something similar to what Try.Net already can do when it displays only one #region from a gist: dotnet/try#90 (comment). But I don't know if there is any way to apply that here.

[LadyNaggaga]

As @svick mentioned something similar to this might be a good idea https://try.dot.net/?workspaceType=nodatime.api&fromGist=8e2ea50af097df663d9c8e19eb8fbf0a&bufferId=TryNodaTime.cs@fragment&canShowGithubPanel=true and use #region to specify the code to display

[rpetrusha]

As you suggested, @pkulikov, I think that the best thing to do here is to include the complete code sample rather than just a region of code, Doing something like linking directly to try.dot.net seems to me to create a confusing experience.

Thoughts, @svick, @LadyNaggaga, and @BillWagner?

[pkulikov]

@svick @LadyNaggaga thank you for the explanation and the example. I've submitted MicrosoftDocs/feedback#489 to track your idea separately.

[pkulikov]

As for this PR, I'll include the complete Program/Main sample to make the snippet interactive.

[BillWagner]

I agree with your thoughts @rpetrusha

I think that the best thing to do here is to include the complete code sample rather than just a region of code.

[pkulikov]

@BillWagner @rpetrusha as soon as dotnet/samples#162 is merged, this PR is ready to merge as well.

[rpetrusha]

Closing and reopening to begin new build.

[rpetrusha]

Thanks, @pkulikov. The code now works in the interactive code runner. I'll merge your PR.