Nullable new aka nullable Constructor

[Applesauce314]

Summary

Proposes a syntax that allows new() to return a null, allowing the use of property initializers where previously a Factory function would have been required.

Problem

Sometimes when you are constructing a instance of a class you may wish to return null. Since new() cannot return null a factory function is often used. However a factory function does not allow access to the languages property initializer features, making code that does this require more boilerplate (specifically parameters passed to the factory function).

public class Gadget
{
    public long? AssociatedWidgetId { get; init; }

    public required string PartNumber { get; init; }


    public static Gadget? Create(Widget widget)
    {
        if (widget.IsGadgetable && CanCreateGadgets)
        {
             //won't compile does not set required PartNumber property
             return new() {  AssociatedWidgetId = widget.WidgetId},;
        }
        else
        {
            return null;
        }
    }
}

//Not Possible
Gadget.Create(currentWidget) { PartNumber ="A" + nextPartNumber", };

Idea/Proposal:

create new syntax for new new?()and for constructors public Ctor?() that indicate the new operation may not return an instance of the object. Property initilizer syntax would then be chainable

public class Gadget
{
    public Gadget?(Widget widget)
    {
        if(!condition)
        { return null; }
        else
        { return new(widget); }

    }

calling

Gadget? currentGadget = new?(currentWidget) { Partnumber = "32", };
var nextGadget = new Gadget?(currentWidget) { Partnumber = "32", };

Advantages

• The use of ? in new?() or new Gadget?() makes it explicit that a null may be returned
• The syntax reduces the need for the nullable static NullableObject? Create() pattern. as a pattern many differnt ways of naming the same method exist Create,Make,CreateGadget,MakeGadget,ConstructGadget ,Construct, etc. A quick search of github and it appears this pattern is extremely common.

Disadvantages

• new has always returned a constructed object, no longer doing so is a big shift from the way things were.

Possible implementation

Since property initializers are already just syntatic sugar for setting properties after new() returns and init; is just syntatic sugar that is converted to a setter that the complier only lets you call during initialization.
so

public Gadget?(Widget widget)
{ }
...

Gadget? x = new?() {PartNumber = "A55",};

could be converted to

public static Gadget? <>Create((Widget widget) { }

...

Gadget? x = Gadget.<>Create(widget) ;
if( x != null)
{
    x.PartNumber = "A55";
}

Issues

• as shown above the nullable constructor would not have access to the private members of the class, there may be alternative ways of implementing it that does not have that constraint.

Issues with Rewriting to valid IL

• Rewriting the nullable constructor into a Create method is probably difficult if left unbounded, so this proposal probably needs to be tweaked to address the issue.
• require the nullable constructor to either return null or return new()

 public Gadget?(Widget widget) where { /*code that evaluates a condition*/}
{ 
    if(condition)
    { return null; }
    else
    { return new(widget); }
}
private Gadget(Widget widget)
{
   \\actual construction here
}
``

- add a prefiltering where clause 
```cs
 public Gaget?(Widget widget) where { /*code that evaluates a condition*/}
{ 
//normal constuctor here
{

Final thoughts

I was surprised there was not a discussion on this already, which hopefully is not because I am bad a searching, or that my idea is silly.
I think that new language features should be simple, be consistent with existing syntax, and reduce the need for patterns in code. I believe this idea meets that criteria.

Addendum

the driving example provided above under this proposal would appear as below

public class Gadget
{
    public long? AssociatedWidgetId { get; init; }

    public required string PartNumber { get; init; }


    public Gadget? (Widget widget)
    {
        if (widget.IsGadgetable && CanCreateGadgets)
        {
              AssociatedWidgetId = widget.WidgetId;
        }
        else
        {
            return null;
        }
    }
}

Gadget x = new?(currentWidget) { PartNumber ="A" + nextPartNumber", };

[HaloFour]

Given that a constructor cannot return null in .NET, the rest of this feature doesn't make much sense. By the time the constructor is called the memory location has already been allocated, and constructors aren't capable of overriding that.

Nevermind, that is what the proposal is asking for. The lead was a tad buried, but that's my fault for not reading the whole thing before commenting.

IMO, allowing for constructors to override the value that is returned, whether that be to return null or some other value, would not be a good thing.

[Applesauce314]

IMO, allowing for constructors to override the value that is returned, whether that be to return null or some other value, would not be a good thing.

I think this proposal addresses that feeling in two ways:

• It not really overriding; a nullable constructor could only return a instance of the class or null, and you could not have both a nullable constructor and a classic constructor with the same parameters.
• The new?() or new ClassName?() syntax makes it explicitly clear what is happening. Nullability is a part of the language now, and I would think that any developer that has worked a project with nullability enabled would immediately recognize what new?() is saying even if they had never heard about the feature.

[HaloFour]

Constructors in the runtime are void methods and are executed after the runtime has already allocated the memory. They aren't able to change the return value, to null or otherwise.

[Applesauce314]

Constructors in the runtime are void methods and are executed after the runtime has already allocated the memory. They aren't able to change the return value, to null or otherwise.

I'm aware of that, I believe this feature could be implemented as a compiler only change. The complier would emit a static method into the IL that would be called instead. The actual .ctor would not be called until the nullable constructor had decided an instance is being created.

while responding to this comment i realized there might be some difficulties with how you might transpile to a hidden create method, i am updating the issues section with some ideas.

[HaloFour]

Yep, short of runtime changes, the compilers only option is to emit a static factory method.

[Applesauce314]

just some background on what drove this idea.

I was adding constructors to a bunch of classes GetRequests where a a specific request type know how to make an instance of it self given a different but related object.
so GetStudentsRequest would know how to extract the data out of a School object to create a request object that properly filters to students in that school.
I did it using constructors because it is very common to start with a relation and then further filter by setting other properties using a property initializer, and these properties are usually init only.
When i got to the end of the list i ended up with one that will not generate a valid request in some circumstances depending on the data in the source object. to support this i either need a try catch on every call, or use the Factory pattern.
I found it bothersome that for this case instead of being able to use the language features , i would either have to add every property to the Create function or make all the property init; into set;.
yes i can work around the issue, but when guiding the other developers i the group, its annoying to have to say ok if you want a GetCableRequest from an Equipment call new Cable(equipment) {props};, but if you want a Cable from a Breaker call GetCableRequest.Create(breaker,prop1,prop2,prop3,etc).

[HaloFour]

Supporting object initializers for factory methods is this proposal: #6602

[Applesauce314]

I had considered a similar approach of tagging arbitrary functions as "factory" functions (which would be super helpful for things like IserviceProvider.GetService but that and #6602 (or honestly any way of writing it) has a much bigger problem of stripping the the init keyword of its meaning. (those inits blocking you? just tag your function with [IsFactory] and you can set them all you want!!!)

what i think is the advantage of this proposal is that it would not change any accessibility rules of properties.

[HaloFour]

The compiler can enforce the relationship between the static factory method and the class on which it has been defined so that the instance returned is in an expected "initialization" state. The language doesn't have to permit that all possible methods can be marked this way or enable this behavior.