Added: LDM notes for May 4 & 6th

[agocke]

May 6, 2020

C# Language Design Notes for May 6, 2020

1. Target-typing ?: when the natural type isn't convertible to the target type.
2. Allow if (x is not string y) pattern.
3. Open issues in extension GetEnumerator
4. Args in top-level programs

May 4, 2020

C# Language Design Notes for May 4, 2020

1. Reviewing design review feedback

[HaloFour]

The feedback on primary constructors is interesting. All of the languages that I'm aware of (namely Scala, Kotlin and F#) all behave more or less as was originally planned, in that the constructor parameters are only captured (effectively fields) in the body of the type and no additional members are surfaced unless you do so manually or apply another keyword which promotes them to public properties. Having primary constructor parameters automagickally become properties in a non-record scenario doesn't feel right to me.

Maybe the problem is trying to marry primary constructors and init-only members? That entire approach makes no sense in my opinion.

[HaloFour]

I'd add Java to that list as well, but only sort of, both because the record feature is experimental in Java 14 and because at least as of now you can't have a primary constructor without the keyword to denote that the type is a record.

[alrz]

having a primary constructor always generate properties is preferred.

So there will be no standalone primary constructor feature? That's unfortunate. The original premise was that it could remove constructor boilerplate for all types?

[YairHalberstadt]

The feedback was negative about making a primary constructor parameters different from positional record parameters. The proposal during the design meeting was that primary constructors would see parameters as "captured" in the scope of the class, while records would generate public properties for each parameter. This is a big semantic divergence, as expressions like this.parameter would be legal in the body of a positional record, but illegal in the body of a class with a primary constructor.

I feel like this is discomfort with what sounds like something strange, but in practice my experience with scala is that this isn't an issue. The user rarely cares whether or not the parameter has been captured, and doesn't really need to know that there's a difference in semantics between them. However the difference in semantics is useful as it allows the compiler to optimize away otherwise unnecessary fields.

This reminds me a little of https://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html

[333fred]

having a primary constructor always generate properties is preferred.

So there will be no standalone primary constructor feature? That's unfortunate. The original premise was that it could remove constructor boilerplate for all types?

I don't think that's what we're thinking this means (or at least that's not what I thought it meant.) We're still exploring the primary constructor space, and the thought is that we make it always do the same thing, regardless of whether it's applied to a record type or not. The notes only mention public properties there, but my theory is that you'd be able to apply access modifiers. We'll be talking about them more tomorrow iirc.

[HaloFour]

@333fred

The notes only mention public properties there, but my theory is that you'd be able to apply access modifiers. We'll be talking about them more tomorrow iirc.

So you'd get properties by default? What would the default access be without a modifier? How does init fit into it if they are already a constructor parameter? I'm sure that these are all questions that are intended to be considered tomorrow but they are what immediately what comes to mind given the design review and your comments.

[333fred]

All good questions that we'll be working on tomorrow :)

[agocke]

@HaloFour if I understand your point correctly, it's that scala effectively does what we were planning by using case. A simple primary constructor generates no public members, while a case class generates read only accessors.

That does seem to work fine for them, but this position was controversial in the review.

[HaloFour]

@agocke

Correct. The details are different for each of the mentioned languages but in all of the cases the primary constructor alone isn't enough to result in public members being generated. What the primary constructor parameters are internally to the class and how you can work with them differ between each of the languages, though.

In Kotlin they are only available as parameters for member initializers and an initializer block, but are not captured for use in other members like functions. You can add modifiers with var or val to make them fields. This is required to use them in data classes which layers on equality and other concerns.

In F# they are available as parameters but also captured and can be used in functions, but not like fields (can't be qualified by this).

In Scala they are indistinguishable from fields. Adding case adds public accessors, equality and deconstruction.

In Java you can't use them without the record keyword which is what applies the rest of the opinions like public accessors and equality.

I'm curious how other languages handle it as clearly there isn't a one-side-fits-all. Out of the above I kind of like Scala's approach the best.

[agocke]

I went back and looked at a bunch of languages here. What we we're generally talking about is "positional records" and what I found was that almost all languages that have positional records design them how you're describing.

There are a few languages, like F# and Rust, that don't really have positional records in this sense. But those languages also have something else in common, which is that they have a separate discriminated union syntax that generates what looks like positional records. My impression here is that concision of representing data models effectively forces a positional-like syntax form. If you want to construct your discriminated unions out of your records feature, I think that implies some form of positional records is necessary. If that doesn't matter then you use a separate syntax for ADTs.

[HaloFour]

@agocke

You could add Swift to that list as well:

enum Barcode {
    case upc(Int, Int, Int, Int)
    case qrCode(String)
}

From what I understand single case unions are pretty common in F#, particularly to model primitive type wrappers.

[MgSam]

I hate the idea of having a magic args variable in scope everywhere if any top-level statement is added to a file. Actually, I hate the idea generally of top-level variables, in general. You guys are considering doing exactly what Neal wrote an issue about not doing a few months ago- which is add a feature which encourages bad programming practices (mutable global state).

Jupyter notebooks will likely be old news in a few years like most programming fads, the decisions you make now will stick around in C# forever. Please stick to the pit of success.

[orthoxerox]

I disagree with you about the args parameter. The way I see it, simple programs must be a natural stepping stone towards complex programs. If you use args in Main you should be able to use args in a simple program and in exactly the same way.

I could agree that perhaps it should only be available in the top level sentences, not in any of the subroutines to nudge people away from globals, even though local functions inside Main have access to args.

[dersia]

IMO it is a good thing to have different behavior between records and classes. If they both behave the same way, why would I use one other the other.
Of course I know there is more differences between records and classes than just the behavior of primary constructors, but I guess a majority of devs that haven't cared about immutability nor records in the past won't see the difference.

With that said I would suggest the following:
For records primary constructors are fine the way they're planned.
For classes primary constructors should create private fields when used this way

Foo(string name, string lastname);

And instead of caring about access modifiers we could just decide that if properties are generated they are always public and { get; set; } instead of init only.
Most of the time properties within classes are used publicly and most devs use classes as they are today with public setters. (no numbers and statistics, just reflecting on the code I have seen so far)
There for I would go with a syntax like this

Foo(prop string name, prop string lastname);

I know that this is introducing a new keyword, but at least it is meaningful and easy to spot on code reviews.
This could than also allow for combinations

Foo(string name, string lastname, prop string displayName);

I also understand that there are cases where one needs private properties or even init-only properties in classes, but I would argue that those cases are so rare, that for those cases one can just write usual classes definitions with regular constructors.