Discussion : Name constructor with keyword instead of name

[ebfortin]

I find it tedious to repeat the name of a class each time I declare a constructor. IDE helps but still, I see no added value to just repeat the class name. I propose the addition of "ctor" keyword to be used in place of the constructor name. Could also use "dtor" for finalizer.

Even IL understands it. It already use that syntax.

Anyone has an opinion on this?

[theunrepentantgeek]

@ebfortin Can you please clarify? Are you talking about use of the type name when constructing an instance, or when declaring the constructor as a part of the definition?

I thought it was the later, but the comment from @jnm2 has me questioning whether I read your proposal correctly.

[CyrusNajmabadi]

It seems highly unlikely C# would change here. Having two ways to do something, where the new way provides only a tiny amount of marginal benefit, would likely not be desirable.

[foxesknow]

Rather than having a new keyword why not just use new ?

public class MyClassWithVeryLongNameBecauseItsBetterForComprehension
{
  public new(string parameter1, int parameter2, bool parameter3, char parameter4, float parameter5)
  {
  }
}

[Rekkonnect]

Rather than having a new keyword why not just use new ?

Yes, that's what I proposed

[AJLProjects]

Don't use new becuase new makes sense for object instantiation, think in terms of English, create me a new cake. In this case, we aren't declarativley creating rather this is just the constructor, so a more appropriate name is init or ctor, or constructor(like js)

[Rekkonnect]

private protected, void, using (for variables) don't make that much sense in English either. That's not an argument in this case, for long as there is connection with the relevant feature, it works. new would mean that it's declaring the constructor that is only called after a new keyword. You won't ever call a constructor outside that context, and it's contained in the type that the constructor is for. You've already typed the name in the type's declaration, and you're declaring the method that will be invoked during an object creation, acting as its initialization.

Sure, constructors don't actually create the objects, they only initialize them. However, just like Java (Object::new), that's how you would break down an object creation:

// an object creation
new Object();

// breaks down into this pseudocode
var memory = ReserveMemory();
memory.Initialize(Object.new);

[DavidArno]

F# uses new too for it's constructors and VB.NET uses New, so it's certainly set a precedent in other parts of the .NET ecosystem.

But for me, any time it's proposed to provide another way of doing the same thing, I have to ask myself "If VS/R# suggested I change existing code from the old way to the new way, would I do it?" For me, it's a clear "no" here. It's definitely a "meh" feature for me.

[jnm2]

@theunrepentantgeek My mistake, they are talking about declaration.

[ebfortin]

@ebfortin Can you please clarify? Are you talking about use of the type name when constructing an instance, or when declaring the constructor as a part of the definition?

I thought it was the later, but the comment from @jnm2 has me questioning whether I read your proposal correctly.

When declaring.

[Austin-bryan]

@ebfortin Just type ctor then hit tab twice.

[DaniilPalii615]

Duplicated class name creates problems when reading code too. When I see in the code public ClassName and then see braces - I think "Oh, it is not class but constructor". And then while working with the class I should to keep in mind that public ClassName() { ... } it is public constructor { ... } in fact. Using constructor keyword would make work with code easier as properties instead of getters and setters.

[arekbal]

Answers here, seem to be very DRY.
ctor(), dtor() ?

Having two ways to do something, where the new way provides only a tiny amount of marginal benefit, would likely not be desirable.

Same goes with arrow syntax method definitions... but everyone agrees they are much more brief.
Java didn't want to change so Scala got created and then Kotlin.
C# didn't want to change, so F# happened, C# suddenly started to change positively.
Pony, Rust, Midori, TypeScript happened, C# suddenly got interested in issues it didn't care about before.
I am not implying it was anybody's thought, just a general wave of programming world changes.
That thing (constructors repeating name of a class) is a low hanging fruit(almost no risk involved) on a path to a more brief, easier to consume programming language.

[CyrusNajmabadi]

Same goes with arrow syntax method definitions...

That was a case where there wasn't a "tiny amount of marginal benefit".

That thing (constructors repeating name of a class) is a low hanging fruit(almost no risk involved) on a path to a more brief, easier to consume programming language.

See: https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/

Or, as Eric Lippert mentioned:

And (2) just being a good feature is not enough. Features have to be so compelling that they are worth the enormous dollar costs of designing, implementing, testing, documenting and shipping the feature. They have to be worth the cost of complicating the language

C# didn't want to change

This has never been the case.

Pony, Rust, Midori, TypeScript happened, C# suddenly got interested in issues it didn't care about before.

You are mistaking 'haven't been actively working on' with 'not caring'. The C# LDM is interested in a wide variety of topics, and has been for decades. But features cost. It is literally zero sum. If you take time and effort to work on a certain set of features, that time and effort is not available for others. So what you see developed are the set of things that are felt to provide a great bang/buck ratio for the development ecosystem out there.

[arekbal]

It is always something or the other. You can't have all the cake right? 🍰 So it makes sense with silly and expensive features, or great but also very expensive features to lay them in priority queue and wait until they probably die off. I don't buy it. I don't see clear way features got selected.
Seems very opinionated. Even me going through some proposals, can see it.
Tell me, what enormous benefit (apart from brevity, which I very much value) syntax arrow definitions rewarded us. Couple of characters less, doesn't reduce the amount of errors in code, actually increases them, because, from body you cannot tell if it returns or not. Leads to confusion between lambda function definition and static definition. Just use brackets dude. Don't forget about them. 🐇
Don't get me started on IQueryable<> vs IEnumerable<>. ^^

[CyrusNajmabadi]

I don't buy it. I don't see clear way features got selected.

It's not anyone's job to get you to buy anything :) I'm simply explaining how language design is actually done. And i'm doing that through my actual experience on the LDM team :)

Seems very opinionated

Yes. That's exactly right. Language design is highly opinionated. First, someone has to be opinionated enough to propose something. Then an LDM member has to be opinionated enough to champion it. Then, all hte opinions of the rest of the LDM are brought in during the design of the feature. 'Opinionated' is one hte best words i could come up with for the process :)

Tell me, what enormous benefit (apart from brevity, which I very much value)

I don't see why the 'apart' part is relevant. It's like saying: apart from the reasons you did this, what were the reasons you did this?

Brevity was the reason. in general the existing statement form added two additional lines, and four extra tokens. For the types of trivial, but common, methods that could use this feature this was a substantive overhead.

Don't get me started on IQueryable<> vs IEnumerable<>.

Ok. Don't get started on that :)

[arekbal]

In not so far future...
Someone asks what was the point of bringing these shortcuts ctor and dtor(or similar), replacing public with pub and namespace-one-line-per-file-declaration instead of brackets:

Brevity was the reason. in general the existing form added X additional lines, and Y extra tokens. For the types of trivial, but common, code that could use this feature it was a substantive overhead. Developers shouldn't have to repeat themselves as much.

[MV10]

#1335

[Korporal]

It seems highly unlikely C# would change here. Having two ways to do something, where the new way provides only a tiny amount of marginal benefit, would likely not be desirable.

@CyrusNajmabadi

Yet you exhibit support for this which seems suffer from the same drawbacks: Another way of writing a switch that "provides only a tiny amount of marginal benefit" - or am I missing something?

[CyrusNajmabadi]

Yes. As i mentioned in the other issue, the feature has already been championed. Meaning the cost of it has already been assessed to be less than the gain overall to the language. It's not the case of:

1. we have switch expressions, now someone wants to come along and add a new feature to it.

It's the case of:

1. we don't have switch expressions. we're adding them. what is the right design for them.

--

Here's another way of thinking about it. Imagine any proposal has a fixed cost of 1000 LDM-bucks. That's expensive and needs to present a lot of end value to the user for the LDM to pay that much. Switch expressions are currently at having value of 10k LDM bucks. So upping that cost to 10,005 to support consistency here is not really that different.

However, having to go and spend the 1k LDM-bucks just to do a new way of doing constructors is just not there. Maybe in the future if the LDM is doing a lot of constructor improvements, and the overall benefit is worth it, this could be rolled into that. But paying so much to get a tiny marginal benefit is non-sensical.

[Korporal]

@CyrusNajmabadi

Yes. As i mentioned in the other issue, the feature has already been championed. Meaning the cost of it has already been assessed to be less than the gain overall to the language. It's not the case of:

1. we have switch expressions, now someone wants to come along and add a new feature to it.

It's the case of:

1. we don't have switch expressions. we're adding them. what is the right design for them.

--

Here's another way of thinking about it. Imagine any proposal has a fixed cost of 1000 LDM-bucks. That's expensive and needs to present a lot of end value to the user for the LDM to pay that much. Switch expressions are currently at having value of 10k LDM bucks. So upping that cost to 10,005 to support consistency here is not really that different.

Of course I am in no position to even estimate cost so I can't comment on that, perhaps you could explain (if you have the time) the cost estimate for some of the proposals we make including this particular one? That can only help us going forward, to understand the true costs of some of the stuff we suggest here.

However, having to go and spend the 1k LDM-bucks just to do a new way of doing constructors is just not there. Maybe in the future if the LDM is doing a lot of constructor improvements, and the overall benefit is worth it, this could be rolled into that. But paying so much to get a tiny marginal benefit is non-sensical.

I'm gonna take some convincing to see the utility in the trailing comma support. Your increasing the scope for unintended errors to go undiagnosed. Right now if someone edits code, copies, pastes etc and in error either removes the true end element or inserts something not intended to be the end element they'll get told off by the compiler.

With this change either scenario is regarded as valid and under the above user edit scenarios a potentially true error will go unreported and perhaps out into the production world. Any developer who claimed this was a real help to them in day to day work would also make me wonder about their skills.

So my vote (if that means anything, which I doubt!) is to deny this.

[CyrusNajmabadi]

Of course I am in no position to even estimate cost so I can't comment on that, perhaps you could explain (if you have the time) the cost estimate for some of the proposals we make including this particular one? That can only help us going forward, to understand the true costs of some of the stuff we suggest here.

Every new feature has a high fixed cost (it's like passing a bill). You have the meetings with everyone involved. The impls, the testing, the context switching, the doc'ing, the shipping. It's a huge fixed cost to even get a feature down this path and this is honestly close to zero-sum. If the time is spent on htat, it's not spent on other things that deliver more value.

However, once you've decided to go down this path and you've paid the fixed costs, then changes/tweaks to something in flight is much less costly. You already hve someone working on the design/grammar/impl/tests/etc. so saying: can you just tweak things to support X is much less costly. Indeed, it basically just rolls into the normal cost that you've already accepted as being worth it to pay for this feature.

Of course, if someone comes along and says "please tweak like so" and that tweaking doubles the cost, then it won't be considered the same as a tweak that basically takes 5 min of time.

[CyrusNajmabadi]

I'm gonna take some convincing to see the utility in the trailing comma support.
So my vote (if that means anything, which I doubt!) is to deny this.

The change was approved. The people who needed to be convinced were convinced :)

Your increasing the scope for unintended errors to go undiagnosed.

What unintended errors?

Right now if someone edits code, copies, pastes etc and in error either removes the true end element or inserts something not intended to be the end element they'll get told off by the compiler.

I don't know what this means. On hte other hand, we have ample experience that shows that supporting a trailing comma is not actually a problem in practice (i.e. all the other places in the language that allow this), and it makes for a definitely nicer experience across all editors. It's not uncommon for people to keep needing to add elements to the end of a list that are very similar to the previous element. Being able to just copy/paste that last element is a routine operation done by many devs across many IDEs/editors across many languages. This routine op has a roadbump in it today that is just being removed. Given the experience that shows this doesn't lead to problems, and given the nicer experience this provides, it's simple to roll this work into the already approved feature which is coming down the pipe.

[Korporal]

Of course I am in no position to even estimate cost so I can't comment on that, perhaps you could explain (if you have the time) the cost estimate for some of the proposals we make including this particular one? That can only help us going forward, to understand the true costs of some of the stuff we suggest here.

Every new feature has a high fixed cost (it's like passing a bill). You have the meetings with everyone involved. The impls, the testing, the context switching, the doc'ing, the shipping. It's a huge fixed cost to even get a feature down this path and this is honestly close to zero-sum. If the time is spent on htat, it's not spent on other things that deliver more value.

However, once you've decided to go down this path and you've paid the fixed costs, then changes/tweaks to something in flight is much less costly. You already hve someone working on the design/grammar/impl/tests/etc. so saying: can you just tweak things to support X is much less costly. Indeed, it basically just rolls into the normal cost that you've already accepted as being worth it to pay for this feature.

Of course, if someone comes along and says "please tweak like so" and that tweaking doubles the cost, then it won't be considered the same as a tweak that basically takes 5 min of time.

@CyrusNajmabadi
So out of curiosity how do you express cost and compare costs? in person hours?

[Korporal]

I'll confine my remarks about the trailing comma to that thread, I apologize for derailing this one!

[CyrusNajmabadi]

So out of curiosity how do you express cost and compare costs?

Historically, by the LDM members using their expertise and experience to weight/order things. It's generally a continuous process, with certain points in product cycles being used to reasses/reorder things.

It's the same way i can read a proposal on a suggested IDE feature and generally give a very precise assessment of the cost to do that feature (including what sort of design tweaks could be considered, and how they would vary the bang/buck outcome of the work).

Because nearly all of the LDM has actually worked with the language for years,and have been involved directly with the both the impl and the end-to-end process to start with a proposal and take it all the way to a released product, it's pretty easy for them to come to consensus here.

Note: not everything works out that way. For example, NRT was something known to simply be so humongous and so impacting across teh language that it was known that the only way to even get a sense of it was to just 'do it'. For something this large, this would then be a continual process of exploration/impl/assessment to see if the direction things were going, and the results that were being achieved would justify the costs involved. But most everything else can be assessed apriori without needing this sort of approach.

Similarly, 'code generators' was felt to have absolutely staggering value to users. However, early explorations into this space also revealed such a huge amount of unforseen work that this was tabled until more adequate funding and a more appropriate time could be found for this.

[AJLProjects]

Please can we re-review this? Clear violation of the DRY principle, and with probably millions of C# classes in existence, this is an impactful change. With regard to @CyrusNajmabadi last comment, how can you know if there is unseen work? This seems like an easy change to me.
UX is just as important as functionality when it comes to language design.

[CyrusNajmabadi]

The "why not" is what I argued against.

Having gone this direction already, I cannot see why not implement this feature.

I'm having trouble reconciling these two statements. In the first you say you're arguing against 'why not'. But in the second, you do ask 'why not implement this feature?'... so you're arguing for 'why not' :)

[Rekkonnect]

Taking words a bit too literally, but I'll still explain.

I'm highly supportive of this feature, and even taken the time to write another comment regarding designing the feature. That being said, I've also taken the time to consider the "why yes" and "why not" arguments.

Fwiw, if we were starting over again, I would push for this. However, given where we are now, I would not want this given the marginal benefit and the trillions of lines of code already out there using the current form.

You're the one that said you are hesitant to vote for this feature due to the fact that the language isn't fresh, but has been around for decades. And to that I say that the exact same argument against file-scoped namespace declarations could be used, but was not significant enough to prevent the feature from making it to the language. And for the record, I'm glad it did.

Even better, there will obviously be an available code fix to transform ctor declartions into their new form. There is literally no reason not to use it once it becomes available, as it's a full-fledged enhancement of an old design. Much like file-scoped namespace declarations, most people will opt-in by running a solution-wide code fix action and path forward. The old option is still there for the ones that don't like the new feature, or don't know about it, or don't care about it.

I hope this has been cleared up. "I don't see why not" in this case meant "we now have whyNot.Count == 0, so please reconsider your view because I support this feature, like lots of others". The design choices are always up to the LDT anyway, and it is not guaranteed if the syntax will make it the way it was initially proposed.

[CyrusNajmabadi]

but was not significant enough to prevent the feature from making it to the language.

Correct, in that case the reasons why were significant enough to warrant it. So it was a 'why' decision. We evaluated why we should do this, and found the benefits substantial enough. I would want the same here.

Much like file-scoped namespace declarations, most people will opt-in by running a solution-wide code fix action and path forward

I have no reason to believe that this will be the case. Indeed, we're not doing this in Roslyn itself (or any of the BCL libs afaict).

[Rekkonnect]

Correct, in that case the reasons why were significant enough to warrant it. So it was a 'why' decision. We evaluated why we should do this, and found the benefits substantial enough. I would want the same here.

This now makes more sense, so the "why not" is not being removed from the list.

I have no reason to believe that this will be the case.

I'm confident enough that many people do this for their projects if they really fancy the new features, once they choose to opt-in. And I personally do it, so I would greatly appreciate a diagnostic paired with a code fix for that purpose, it wouldn't be that hard to implement.

Indeed, we're not doing this in Roslyn itself (or any of the BCL libs afaict).

I'm assuming you're referring to whether you're doing this refactoring in the code itself, not whether the code fix will be developed.

[CyrusNajmabadi]

I'm assuming you're referring to whether you're doing this refactoring in the code itself,

Correct.

not whether the code fix will be developed.

Correct. The fixer is already available and shipped with the lang feature.

[deeprobin]

I think a syntax for static constructors or destructors wouldn't be bad either.

Current

static MyClassName() {}

~MyClassName() {}

My idea

static constructor { // I think these paratheses are in this case unnessecary because no static ctor or destructor can have parameters

}

destructor {
}

[Rekkonnect]

Building on top of this idea, since static constructors are not really "constructors" (they are conveniently called as such internally), but static initializer blocks, we could use something similar like:

static init
{
}

[jnm2]

I'm not seeing a difference between the term "initializer block" and "constructor" for either the instance or static cases.

[ds5678]

Would this be considered an Any Time feature or a Likely Never feature? From reading the chat, it seems like the LDM is strongly opposed to devoting much time to this. However, would you accept a community contribution with a clean implementation?

[CyrusNajmabadi]

This is definitely not 'any time'. It's also not 'likely never'. It is in need of an LDM champion who would argue it through the LD process and get this accepted. Note: i am not that person. I'm personally against it (you can see my reasons in the thread). But if someone else wanted it and convinced the LDM (including just getting it into the 'any time' bucket) then it could be done.

--

However, would you accept a community contribution with a clean implementation?

It would not be accepted :) Note, i'm trying to say that gently and not come across as dismissive of it. While that would personally be really nice for you to do and would be appreciated (for an any-time feature), it's absolutely against the stated procedures and processes csharplang and Roslyn follow. So i would not want you to go spend that effort and then end up sad if/when it was summarily rejected.