Julien Couvreur jcouv

For current PR:

Should we accept a general pattern following .. in a slice_pattern? Answer: let's say yes for now. Allowing some nested patterns versus allowing all isn't a deep change. We can add that before shipping.
We should define the exact binding rules for any of these members and decide if we want to diverge from the range spec. Answer: we should stick to the same behavior as ranges. In short, we bind to indexers if available, otherwise special Slice method.
Should extension methods play a role in sliceability? Answer: we may change that later (for slicing and slice pattern, thus transforming an error scenario into a working scenario) but should assume "no" for now (keep the existing rules from ranges).
The pattern {..} tests for expr.Length >= 0. Should we omit such test (assuming Length is always non-negative)? Answer: this doesn't need to be spec'ed, it is an implementation detail. We are free to change/optimize what we emit for this case. I'd start without the optimization. We ca

(Taken from dotnet/roslyn#20648)

At one time the implementation of tuples recognized that tuples and their underlying types are distinct types. Later, the LDM decided that these should not be distinct types. We (mostly) modified the compiler’s language behavior to respect the LDM decision, but we have not modified the APIs accordingly.

Our compiler guidelines include this design point:

As a rule, the public APIs exposed by Roslyn should reflect the language view of the program, not the lowered or implementation view. For example, a Symbol's Name property should reflect the name from the language point of view if there is one; we have a separate MetadataName (internal) property to represent the implementation view.

In order to align our APIs with the language view for tuples, I propose to make the following changes:

class Outer<T> where T : Outer<T>?
{
    void M0(Outer<T> x0)
    {
        T y0 = x0 as T;
        y0?.ToString();
        y0.ToString();
    }

Do we look at tuples like Pair<T1, T2> or like locals?

// current behavior is similar to Pair<T1, T2> except that we’re able to initialize the state of the fields in tuple literals
static void M(string? x, string y)
{
    (string, string) t = (x, y); // warning: (string?, string) mismatch
    t.Item1.ToString();          // warning: may be null
 var t2 = Identity(t); // infers `(string, string)`

Proposal: A switch with a pure test sets the state of the tested variable to maybe-null at the entrance of the switch.

In that context, I think Mads is pushing back on {} counting as a “pure test” in a switch. If I understood, he is saying a {} => … branch on its own doesn’t open the possibility of a null (it’s not a pure test). But a {} => … branch followed by another branch would be.

Note: if we treat {} as a pure test, then we could offer a fixer to change it to _ if you didn't want to imply a null test.

Resolved in LDM 3/6/2019: {} and derived is Base are not "pure tests".

Where should the null-state be set to MaybeNull?

1>------ Build started: Project: CodeAnalysis, Configuration: Debug Any CPU ------ 1>Diagnostic\ExternalFileLocation.cs(49,30,49,36): warning CS8610: Nullability of reference types in type of parameter 'obj' doesn't match overridden member. 1>Emit\CommonPEModuleBuilder.cs(166,40,166,52): warning CS8616: Nullability of reference types in return type doesn't match implemented member 'IDefinition? IReference.AsDefinition(EmitContext context)'. 1>Emit\CommonPEModuleBuilder.cs(235,40,235,61): warning CS8613: Nullability of reference types in return type doesn't match implicitly implemented member 'IAssemblyReference IModuleReference.GetContainingAssembly(EmitContext context)'. 1>Emit\CommonPEModuleBuilder.cs(76,32,76,36): warning CS8612: Nullability of reference types in type doesn't match implicitly implemented member 'string? INamedEntity.Name'. 1>PEWriter\ExceptionHandlerRegion.cs(137,40,137,53): warning CS8608: Nullability of reference types in type doesn't match overridden member. 1>CodeGen\ArrayMembers.cs(29

1>------ Build started: Project: CodeAnalysis, Configuration: Debug Any CPU ------ 1>CommandLine\CommonCompiler.ExistingReferencesResolver.cs(42,73,42,89): warning CS8610: Nullability of reference types in type of parameter 'baseFilePath' doesn't match overridden member. 1>CommandLine\CommonCompiler.LoggingMetadataFileReferenceResolver.cs(27,73,27,89): warning CS8610: Nullability of reference types in type of parameter 'baseFilePath' doesn't match overridden member. 1>Diagnostic\SourceLocation.cs(68,36,68,46): warning CS8608: Nullability of reference types in type doesn't match overridden member. 1>Emit\CommonPEModuleBuilder.cs(235,40,235,61): warning CS8613: Nullability of reference types in return type doesn't match implicitly implemented member 'IAssemblyReference IModuleReference.GetContainingAssembly(EmitContext context)'. 1>CodeGen\MethodBody.cs(124,42,124,53): warning CS8615: Nullability of reference types in type doesn't match implemented member 'IImportScope? IMethodBody.ImportScope'. 1>CodeGen\Metho

1>------ Build started: Project: CodeAnalysis, Configuration: Debug Any CPU ------ 1>Operations\Operation.cs(72,29,72,33): warning CS8612: Nullability of reference types in type doesn't match implicitly implemented member 'ITypeSymbol IOperation.Type'. 1>Syntax\InternalSyntax\SyntaxList.WithManyChildren.cs(79,41,79,48): warning CS8609: Nullability of reference types in return type doesn't match overridden member. 1>Syntax\InternalSyntax\SyntaxList.WithManyChildren.cs(89,42,89,51): warning CS8610: Nullability of reference types in type of parameter 'parent' doesn't match overridden member. 1>Syntax\InternalSyntax\SyntaxList.WithThreeChildren.cs(86,42,86,51): warning CS8610: Nullability of reference types in type of parameter 'parent' doesn't match overridden member. 1>Syntax\InternalSyntax\SyntaxList.WithTwoChildren.cs(76,42,76,51): warning CS8610: Nullability of reference types in type of parameter 'parent' doesn't match overridden member. 1>PEWriter\TypeNameSerializer.cs(24,43,24,79): warning CS8600: Convert

	using System;
	using System.Collections.Generic;
	using System.Diagnostics;
	using System.Reflection;
	using System.Runtime.CompilerServices;
	using System.Runtime.ExceptionServices;
	using System.Threading.Tasks;
	using System.Threading.Tasks.Sources;

	[assembly: CompilationRelaxations(8)]

	class C
	{
	static async System.Collections.Generic.IAsyncEnumerable<int> M()
	{
	System.Console.Write(""1 "");
	await System.Threading.Tasks.Task.CompletedTask;
	System.Console.Write(""2 "");
	yield return 3;
	System.Console.Write("" 4 "");