Added: Notes from October 26th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-10-26.md

Agenda

• Pointer types in records
• Triage

[PathogenDavid]

For pointer types on records: Will they be permitted when equality, etc is explicitly implemented or will they not permitted at all? As someone who uses records primarily for their ability to work with with, it'd be disappointing to see them eliminated in all cases.

If they're going to be forbidden in general, they should at least be permitted for non-auto properties so that you can do something like this:

record R
{
    private IntPtr _MyProperty;
    public int* MyProperty
    {
        get => (int*)_MyProperty;
        init => _MyProperty = (IntPtr)value;
    }
}

[PathogenDavid]

To answer my own question:

The spec change indicates it is only fields:

It is an error for an instance field of a record to have an unsafe type.

And now that the compiler changes are merged we can double-confirm: (SharpLab)

using System;

public unsafe record R
{
    private IntPtr x;
    public int* X
    {
        get => (int*)x;
        set => x = (IntPtr)value;
    }
    
    // error CS8908: The type 'int*' may not be used for a field of a record.
    //public int* Y;
}

[PathogenDavid]

Finally, the runtime has talked several times about enabling pointer types as generic type parameters, and if they were to do so then the rules for this might fall out at that time.

Are there any issues about this besides dotnet/runtime#13627, or is this just internal murmurings? This is something I find myself wanting more and more lately to the point where I've been tinkering on a formal proposal to add it without runtime support (under the presumption that it's too niche to ever receive runtime support.)

[333fred]

That is the tracking issue afaik. @tannergooding might know more.

[tannergooding]

That is the issue I opened to track it yes, but whether or not it happens likely depends on feedback, use cases provided, etc.

It would be great if you could +1 it and provide feedback on the scenarios it would enable for you.

[PathogenDavid]

I did +1 it, will try to gather some of the places this has caused me trouble in recent memory.

[TonyValenti]

Im a huge fan of the Visual Basic style base call for constructors. Glad to see it is being considered!

[huoyaoyuan]

Finally, we considered simply allowing the base call to be done in the body of the constructor instead, a la Visual Basic.

Does CLR allow choosing which base constructor to call? I think this is very dangerous for verification. VB requires base constructor call to be the exactly first statement of constructor.

Allowing statements before base constructor call will cause more problems about member initialization. Generally I don't expect this.

[HaloFour]

Allowing statements before base constructor call will cause more problems about member initialization. Generally I don't expect this.

I would expect that any such feature would limit such code to the kind of code that is already allowed prior to the base constructor call which forbids access to this and instance members except for fields declared on the current type. Currently you might have to twist your code into knots in order to evaluate expressions that can be used as arguments to the base constructor.

[Unknown6656]

I absolutely agree with HaloFour.
I do not see any problems with statements coming before the base call -- as long as they do not access this or instance members.

[theunrepentantgeek]

Prohibiting access to this and to instance members would eliminate some very useful scenarios.

Constructor chaining in Delphi's Object Pascal language was achieved by using the inherited keyword to call the base constructor. IIRC, you could do this at any point, but doing so was required.

One of the very useful (idiomatic) uses of this was to allow subclasses to override the default values for initialization of properties configured by the base class. Doing this not only requires access to this during execution of the constructor, but the ability to call virtual methods as well.

(Cue the zealots screaming heretic and calling for me to be stoned.)

[HaloFour]

@theunrepentantgeek

It was idiomatic to call the virtual members of the current class before Inherited? Wouldn't that result in the base constructor overwriting whatever was initialized before calling the base constructor?

[theunrepentantgeek]

Theoretically, yes - but in practice it wasn't a problem for well designed class hierarchies.

It's been a long while since I wrote any Delphi code, but I only remember one time where I shot myself in the foot and that was because I was being "clever".

[Unknown6656]

or borrow from Java and allow anonymous types to actually inherit from existing types/interfaces.

Yes please. I'd wanted to have "anonymous inheritance" in C# ever since I first found out about them in Java.

[CyrusNajmabadi]

Prohibiting access to this and to instance members would eliminate some very useful scenarios.

That's already prohibited, so there would be no change there. We don't really see changing anything in that regard. This is much more about just being able to have/use locals (including static/non-static local functions).

[Unknown6656]

I meant introducing anonymous inheritance as a separate language feature