Added: LDM notes for August 22, 2018

[agocke]

https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-08-22.md

Agenda

1. Target-typed new
2. Clarification on constraints with nullable reference types enabled

[MgSam]

Is there an actual use-case for target-typed new other than "it's cool so let's do it"?

I am not a fan of adding more syntax to do things we can already do that is equally or more verbose than the current syntax.

[HaloFour]

@MgSam

IIRC it was mostly about enabling more succinct declarations in scenarios where var is unavailable, e.g. fields.

[MgSam]

Benefit (minor, rare) does not seem worth the cost (duplicative syntax making code harder to read because its yet another thing to think about).

[bbarry]

void M<T, U>() where T : class, U : T` {}

That looks like several syntax errors compounded on itself, is there something missing there (and what is the backtick for)?

Did you mean this instead:

void M<T, U>() where T : class where U : T {}

[alrz]

@MgSam

It is kind of a counterpart to the default literal, but here you can actually instantiate the object. I'd expect some code style option to limit the usage. still, it's possible for a feature to get cut in the last minute, so please do share your concerns.

[MgSam]

@alrz I appreciate the hard work you put in developing the feature- I just don't think there's enough benefit to it - or enough support for it for it. Roughly half of the votes are downvotes #100 (as we know a hundred votes on this board is a huge amount).

[jnm2]

Wow, I would not have thought of new() as controversial at all. I've been eager for it nearly every time I use a generic type's constructor. How odd! Look at the huge imbalance in the votes on the top two comments, too!

[TheUnlocked]

I think a big issue with it is readability. new(1, 2) tells you nothing without context, and can be somewhat confusing to developers that are used to new having a type attached. While it would save on a lot of characters, sometimes more is more and less is confusing.

[theunrepentantgeek]

@TheUnlocked A similar argument can be - and has been - made about the use of var and default, but the simple observation is that in most codebases they are only used where the type is already obvious.

[CyrusNajmabadi]

@TheUnlocked A similar argument can be - and has been - made about the use of var and default, but the simple observation is that in most codebases they are only used where the type is already obvious.

Indeed, and i'm sure the IDE will have similar options there that exist for "var". i.e. code-style rules to say when a target-typed-new is allowed. So:

'new' preferences
When variable type is apparent	Prefer 'new' with type or Prefer 'new' without type
Elsewhere	Prefer 'new' with type or Prefer 'new' without type

[DavidArno]

@jnm2,

I think the controversy around new() has two parts:

1. Whilst,

private readonly Dictionary<(Foo foo, Bar bar), List<Baz>> bazByFooAndBar = new();

will be nice, being able to say:

private readonly var bazByFooAndBar = new Dictionary<(Foo foo, Bar bar), List<Baz>>();

just feels like it fits in with current idioms more.

2. Your other example on Champion "Target-typed new expression" (VS 16.8, .NET 5) #100, of declaring the field, then setting it in the constructor with bazByFooAndBar = new(initialValues);, falls into the category of the type not being obvious.

Target-typed new will be a nice addition, but it feels inelegant compared with alternatives. Thus the mixed reaction, I guess.

[Joe4evr]

Target-typed new will be a nice addition, but it feels inelegant compared with alternatives.

Except that the alternative for fields requires solving the Halting Problem. 🙃

[4creators]

IMHO we should drop targeted new - too much pushback. If proposal is capable to gather almost equal number of up votes and down votes it should be dropped.

There is a very large body of championed proposals which have far greater support and do not raise controversy which we should prioritize. Try not get syntactic sugar everywhere while you lack more fundamental capabilities in C#. Try to do generic numeric algorithms 😆

[jnm2]

@Joe4evr

Except that the alternative for fields requires solving the Halting Problem.

I don't think it does. It requires the same cycle detection that we currently apply to consts, if I understand properly. Types are statically known and do not require running the problem.

[gafter]

Types are statically known and do not require running the problem.

If you can use var for fields then types are not statically known. In any case, we do not have much LDM support for declaring API elements (e.g. fields) without specifying pertinent aspect of the element, such as its type.