Make the use of new be optional when it can be inferred that a new object is being created

[kkukshtel]

In most use cases, it's clear when a new object is being created. Traditionally, creating new instances of a type has been like:

class MyType() {
  public MyType(int x, int y, int z){}
}
MyType a = new MyType(1,2,3);

The addition of var made this a bit more simple:

var a = new MyType(1,2,3);

And then the ability to omit the type itself as part of the construction call if the type could be inferred:

MyType a = new (1,2,3);

Inspired a bit by the new collection initializer syntax, I'd like to see this taken a step further, and make something like this possible:

MyType a = (1,2,3);

The idea is that, you don't really need to use new in this case. It's clear from use that a is being a assigned to a new instance of MyType. Similar to how just new() will throw a compiler error if the type isn't declared, this would not be a valid type instance creation and instead would "fall back" to assuming a is a Tuple<T1,T2,T2>:

var a = (1,2,3); //implicilty a Tuple

The tuple question is probably the biggest here, especially with the ability to achieve similar behavior through static implicit operator to add in the ability to treat use a tuple in place of object creation. I do this below:

public record Point(float X, float Y) {
    public static implicit operator Point((int, int) tuple). {
        return new Point(tuple.Item1, tuple.Item2);
    }
}

public static Point[] GetPolyPoints  => [
  (1,2),(1,2),(1,2),(1,2)
];

In a case where something like this is defined, the compiler would use the user defined implicit operator. However, if this isn't defined, it would attempt to use a constructor that matches the signature. If no valid ctor signature is found, there would be a compiler error (as it is trying to assign a tuple to an object):

//assuming the same MyType class
MyType a = (1,2,3,4,5); //produces a compiler error

If an implicit ctor is defined, I could see there being some warning as well that it's using the operator instead of the ctor.

I think the argument against this is maybe mostly a philosophical one — being able to use new is a more obvious signal of an allocation, but it's also not hard to understand that creating a new object is an implicit allocation already, with or without a new. I think if the idea is received well enough but maybe too radical, I could also see hiding it behind some compiler flag like .

For backwards compatibility, I can't think of any cases where this would break existing code. Given the above, is a user defined implicit operator exists, the compiler would fall back on that and use the same behavior.

As a tease, it's also just really nice to see code like this possible (leveraging latest c# features and my proposal):

record Point(int x, int y);
Point[] arr = [(1,2),(3,4),(5,6)];

Would love to know what people think, and thanks for reading!

EDIT: Just so it's clear, as I mentioned it in the title but not in the actual body of the proposal, the idea is not to get rid of new. Only to make it optional when its use can be inferred.

[CyrusNajmabadi]

this sounds like a good case for SGs. Add such an implicit operator to the type if non-existent :)

[jnm2]

This would only work for types which are declared in the same compilation.

[HaloFour]

Until extensions, which could then define conversion operators from tuples.

[jnm2]

That hasn't switched to a foregone conclusion yet these days, has it?

[En3Tho]

This is something I've thought about when designing my imaginary language. The main downside is that it is really easy to obscure the code. It looks nice in these small very concrete examples but reading something like DoSomething((1,2), "abc", (1, 2, "bcd")) in arbitrary code is quite confusing.

In the end my personal preference is F# approach where new keyword is omitted and you just end up with DoSomething(MyClass(1, 2), "abc", MyOtherClass(1, 2, "bcd")) is better. Because in the end constructor is just a function.

And with shapes I think you might be able to define your own op_Implicit extension for any class you want to achieve this way of tuple-based syntax where you really need it.

[kkukshtel]

The main downside is that it is really easy to obscure the code. It looks nice in these small very concrete examples but reading something like DoSomething((1,2), "abc", (1, 2, "bcd")) in arbitrary code is quite confusing.

I think the main question here would be "confusing for who"? This is already possible:

DoSomething(new (1,2), "abc", new (1, 2, "bcd"))

Omitting the new here feels about the same in terms of legibility, and (as mentioned above), a mismatched tuple in place of a parameter would throw a compiler error already. One thing I could maybe see instead is something like:

MyType a = $(1,2,"bcd")

So the $ is shorthand for new and would indicate an allocation. There is also some symmetry between the idea of the $ as a signal for interpolation and the idea of $() to construct an object. That said, the thrust of the idea is to make object creation as trim as possible, so adding what is effectively a macro for new isn't the greatest solve. I think if legibility is an issue, that's more on the programmer to determine where the specificity needs to exist and for which audience.

In the end my personal preference is F# approach where new keyword is omitted and you just end up with DoSomething(MyClass(1, 2), "abc", MyOtherClass(1, 2, "bcd")) is better. Because in the end constructor is just a function.

This is definitely nice but use can still be inferred from the DoSomething method parameters. You don't need the type names (unless you want them for verbosity when you need them). I'd argue that C#'s current version of new is a better solve in this case, though if you want a full type name doing new MyOtherClass( is a worse experience than F#'s.

[En3Tho]

I think the main question here would be "confusing for who"? This is already possible:

Yeah and this is totally obscure, in my opinion :) I do believe that target typed new has very few good applications and thay are mostly one-line like field initialization. Example above feels like an obfuscation to me honestly. And I don't think it's a good idea to obfuscate things further.

I can understand the desire to reduce amount of keystrokes but at the same time I still think that there should be a balance between brevity/elegance on one hand and readability on the other. The problem is that we often don't think about others.

Also, as I and others in this thread have mentioned, there is ongoing work on extensions (previously called shapes) and this behavior could be achieved with a source generator that would just implicitly extend types with an op_Implicit member. So there won't be a need for a dedicated language feature.

[kkukshtel]

I can understand the desire to reduce amount of keystrokes but at the same time I still think that there should be a balance between brevity/elegance on one hand and readability on the other. The problem is that we often don't think about others.

The argument the C# team makes here and I'll make too is that the other options are still available and most new language syntax features are opt-in. So it's there when you want it, but you could also just as easily have an analyzer enforce it not to be used.

I'm interested in the shapes/extensions work though — can you point me to it?

[En3Tho]

@kkukshtel #5497

[erik-kallen]

Just, why?

IMO, new for an object creation reads well, and it also helps with Intellisense (var x = new |, and I get auto completion).

[HaloFour]

It's not good enough to be optional, it has to be widely applicable and make sense. It's not a race to make C# as terse as possible.

[spydacarnage]

costs.Add(new StorageCost(this, new StorageBundle(modCosts.StorageCosts[c])));

With target typing, you can already shorten this to:

costs.Add(new(this, new(modCosts.StorageCosts[c])));

Removing the new keywords adds an extra level of comprehension deficit, IMO.

[erik-kallen]

I still don't see the point in removing a few chars. If this is what is most importan to you, why don't you use Perl?

[DavidArno]

Just, why?

Because these ideas are worth exploring. If such ideas weren't explored, we'd not have target-typed new for example. It doesn't mean all such ideas will have merit, but those ideas are always worth considering, even if they are rejected afterwards.

For me, the line from @spydacarnage's example neatly shows how older versions of C# were needlessly verbose:

costs.Add(new StorageCost(this, new StorageBundle(modCosts.StorageCosts[c])));

There's two obvious ways that the language could have gone in addressing that. The F# way of not requiring new:

costs.Add(StorageCost(this, StorageBundle(modCosts.StorageCosts[c])));

or the target-typed new approach that C# eventually did take. I think the challenge with this proposal of combining the two lies in what happens with types that have constructors that take zero or one parameters. For example, a line of code that I wrote only yesterday that uses Goblinfactory.Konsole functionality:

var rows = console.SplitRows(new(0), new(1), new(1), new(1));

could become:

var rows = console.SplitRows((0), (1), (1), (1));

From a human perspective, the idea that (0) isn't just a superfluous use of brackets, but is shorthand syntax for new Split(0) is already a challenging one to deal with. From a compiler's perspective though, the ambiguity is significant. It's already significant enough that the idea of (0) could represent a one-element tuple has been firmly rejected (other languages, eg Python working around that with (0,) style syntax). This would take that ambiguity to another level though. And it would be even weirder with zero-parameter constructors:

private readonly MyService myService = new MyService(new MyPersistence(), new Logger());

versus:

private readonly MyService myService = ((), ());

It's for this reason that I therefore do not think this a good proposal.

[kkukshtel]

@DavidArno I really appreciate you thinking through this in good faith and think this is some really great feedback. For what it's worth though, in your example, I think what's already possible in C# (target-typed new) could produce an already ambiguous scenario that removing new wouldn't make better or worse:

private readonly MyService myService = new(new(), new());

I think this is equally ambiguous as:

private readonly MyService myService =((), ());

or even

private readonly MyService myService = new ((), ());

In this case (imo), target-typed new and my proposed optional new both produce bad outcomes for the code. But based on this logic though we should then not have target-typed new. But we do have target-typed new. So I'm not sure how to reason about the difference here. They are both bad here in different ways.

I'm interested too though — what would you think about using a different character? I think the tuple ambiguity for empty ctors is real, but what about instead using curly braces, as they already are used for ctor operations with static constructors. So something like:

private readonly MyService myService = {{}, {}};

This has parallels to how JS does object construction, as well as similarites to things like Zig, though Zig uses a . as well:

const target = b.standardTargetOptions(.{});

C99 struct Initialization is also sort of similar:

sg_pipeline_desc pip_desc = {
    .layout = {
        .buffers[0].stride = 28,
        .attrs = {
            [ATTR_vs_position].format = SG_VERTEXFORMAT_FLOAT3,
            [ATTR_vs_color0].format   = SG_VERTEXFORMAT_FLOAT4
        }
    },
    .shader = shd,
    ...
};

So maybe something like

MyService myService = .{.{}, .{}};

Again not sure if this is any better or worse than target-typed new. Because it's optional and we want to solve for readability — I'd choose something honestly that mixes a few different options:

MyService myService = .{new MyPersistence(), new Logger()};
//or
MyService myService = (new MyPersistence(), new Logger());

Curly braces may pose an issue though with static ctor stuff though, or result in something I think is a little weird:

MyType a = {{}{}, {}};

This part specifically:

{}{}

I think the compiler would be fine with it and you would likely never do it, but it's weird to see an empty ctor construction followed by an empty static ctor. Adding a param is maybe okay but also may look like a ctor?

MyType a = {{}{myParam = 4}, {}};

It's a weird one to square. C# already has language syntax features that can produce hard to read code, but that doesn't mean those features shouldn't exist — just that they should be used when it makes sense. Similarly, you could make every variable have a single letter name, which would produce likely harder to reason about code, but C# doesn't stop you from have short variable names. It puts the control in the programmer to decide, contextually, what makes the most sense.

I think making new optional is one of those things. It's not meant to be a holistic replacement for ever using new, just only that it should (and could!) be an option if we want to omit it in scenarios where its use can already be inferred.

[CyrusNajmabadi]

I think we would be unlikely to do anything here as the feature is already syntactically and semantically legal c# in the presence of implicit operators.

Imo, if you want tuples to legally convert to your types, then opt into that with such an operator.

And, if you want that for all your types, write a generator that adds such an operator for you.

[HaloFour]

My request is explicitly not about syntax, it's about having the option to omit new.

That is a syntax request.

[kkukshtel]

I think maybe my definition of syntax change is off then, or that any change to the front-facing parts of the language (compared to compiler, etc.) is considered syntax. Regardless, my question stands: "is there anything that can be done when new can be inferred".

[CyrusNajmabadi]

@kkukshtel I thought it had already been mentioned. Add implicit operators from tuples to your types. (And you can even have an SG add these for you).

[HaloFour]

Without a concrete alternative there really isn't a conversation to be had. It's not a goal to make the new keyword optional and effort isn't going to be spent trying to figure out alternatives. And given that the code without new is already legal C# and means something different, that seems like it would not be considered a worthwhile alternative. So you'd be replacing syntax using a keyword with some other syntax to denote that ceremony.

[theunrepentantgeek]

is there anything that can be done when new can be inferred

I think this is the crux of the problem.

It's easy to present a short sample piece of code where object construction can be inferred by someone reading the code. Maybe even easily inferred.

But short sample pieces of code aren't representative of working code in real systems.

Forcing anyone to read the code to infer guess at where object creation is happening makes code measurably harder to understand.

If you're working on systems where additional cognative load isn't an issue, I confess I'm kinda jealous. Working on systems with a million lines of code or more, I'll seize any opportunity to make code easier to understand, not the reverse.