Added: LDM notes for April 1st, 202

[agocke]

C# Language Design Notes for April 1, 2020

1. Function pointer design adjustments

2. field keyword in properties

[Joe4evr]

If lazy initialization is a common case, that seems likely to require differing property types, as the backing field would often be nullable, but the initialized field would be not nullable.

Is it not possible for the compiler to simply ignore the warning when it generates the field?

public Foo LazyInstance => field ??= new Foo(42); // just don't report an initialization warning 4head

we probably need to find what scenarios are served by that design

There's also a scenario in Blazor where you need to call a base method if you have some data changing outside of an event:

public ModelType Model
{
    get;
    set
    {
        field = value;
        StateHasChanged(); // forgetting this call will not re-render the component so the change won't be visible
    }
}

Sure, it's similar to the INPC example, but it's also proof that another case is out there.

Additionally, can get => field; be simplified to get; when field is already in use in the setter? It's a bit minor, but may be worth considering.

[CyrusNajmabadi]

@Joe4evr

Additionally, can get => field; be simplified to get; when field is already in use in the setter? It's a bit minor, but may be worth considering.

Yes, that's how we're currently viewing it :)

[Thaina]

Do we have any example of the use case and how to use function pointer in C# ? How many thing it capable?

And also, do the field identifier work with event's add/remove ?

[333fred]

See https://github.com/dotnet/csharplang/blob/master/proposals/function-pointers.md for function pointers.

[Thaina]

@333fred Thank you very much

[bondsbw]

#133 is the proposal that provides backing fields of different types, and provides for multiple fields scoped to a property.

It also provides the same for events.

I mentioned this in the comments, that #133 and #140 are not exclusive. Together they cover simple and slightly more complex cases.

[huoshan12345]

the field identifie can be used as ref field, can it?

[Joe4evr]

@huoshan12345 Yes, that's the intent.

[MgSam]

@Joe4evr

Additionally, can get => field; be simplified to get; when field is already in use in the setter? It's a bit minor, but may be worth considering.

Yes, that's how we're currently viewing it :)

This would be extremely useful. When auto-implemented properties can't be used, I'd venture to guess the logic goes in the setter and the getter is just a simple read probably > 90% of the time. Cutting the extra noise off of that would be great.

[DaZombieKiller]

The thought of being able to simplify INotifyPropertyChanged-esque implementations down to something like this:

public string Property { get; set => ChangeAndNotify(ref field, value); }

Is incredibly appealing, and has me excited to see this usable. Would I be wrong to think that I could also write public ref int Property => ref field;?

[YairHalberstadt]

@DaZombieKiller I think source generators might be a better solution to this. If we get partial properties this might be possible:

[NotifyPropertyChanged]
public partial string Property { get; set }

#3301 (comment)

[DaZombieKiller]

@YairHalberstadt I absolutely agree. Although I'd be satisfied with using the field keyword for it in the meantime, as I imagine source generators are a bit further away.

[YairHalberstadt]

Source generators are planned for C# 9, although they're still in a prototype phase.

[MgSam]

Source generators are planned for C# 9, although they're still in a prototype phase.

Not according to the Milestone tag on it. #107

[MgSam]

I must say these notes are remarkably prescient for being over 1800 years old. :)

[333fred]

Note that source generators are not replace/original. The source generator changes we're planning are really a compiler feature, not a language feature, so I wouldn't really call them part of C# 9. See https://github.com/dotnet/roslyn/blob/features/source-generators/docs/features/source-generators.md and https://github.com/dotnet/roslyn/blob/features/source-generators/docs/features/source-generators.cookbook.md.

[MgSam]

Note that source generators are not replace/original. The source generator changes we're planning are really a compiler feature, not a language feature, so I wouldn't really call them part of C# 9. See https://github.com/dotnet/roslyn/blob/features/source-generators/docs/features/source-generators.md and https://github.com/dotnet/roslyn/blob/features/source-generators/docs/features/source-generators.cookbook.md.

Interesting. Is there an issue to discuss these changes specifically?

Reading over those two documents, this feature strikes me as being a lot more similar to T4 templates than it is to the replace/original concept of source generators (where AOP seemed to be one of the primary motivations).

Pros:

• Has access to the compiler's full analysis of your code.
• Runs at compile time.
• Additive generation has a lot of good use cases.
• Will have first class IDE support.

Cons:

• Runs only at compile time. (T4 supports run-time templates as well).
• Runs at every compilation (T4 is normally run on-demand. For many use cases you don't want your generator running with each compile (for example, you're using a template which generates an ORM model based on database schema- probably not something you want running over and over again on compilation))
• Doesn't support the majority of AOP scenarios (logging, retries, etc)
• The suggested support for INotifyPropertyChanged seems limited in its usefulness. It would only be useful for auto-implemented properties. As soon as you need to write a custom getter/setter you lose all benefit. The appeal of AOP for INotifyPropertyChanged is you could just apply a single attribute at the class level and have it inject notification for every property.
• Doesn't provide a templating language, so writing the code that will be generated doesn't sound like a great experience.
• Users won't necessarily have access to the generators themselves, compared with T4, where you usually have the T4 files to mess with yourself.

All in all I'm not convinced this proposed compiler feature as it stands currently really adds enough benefits over the current tooling. Even worse would be if the design made it more difficult to add true AOP to the language at some point in the future.

[CyrusNajmabadi]

en worse would be if the design made it more difficult to add true AOP to the language at some point in the future.

AOP is a non-goal.

[MgSam]

en worse would be if the design made it more difficult to add true AOP to the language at some point in the future.

AOP is a non-goal.

For this feature. Is it a non-goal forever?

I thought the part in the spec about "There are already well supported tools and techniques for achieving these kinds of operations, and the source generators proposal is not aimed at replacing them." was particularly hand-wavy, given one of the main reasons people wanted replace/original was that those "well-supported" tools actually aren't that well supported or widely used and suck in a lot of ways (PostSharp).

[CyrusNajmabadi]

Is it a non-goal forever?

Who can say? :) There's no one thinking about it currently.