gafter on master
Propose Feb 11 agenda (#2187) (compare)
It's not a "feature that isn't implemented;" it's a thing that is not a feature of the language.
What are you trying to say here?
The question to ask is not "why isn't this there?" but "should this be there at all?"
Asking why it can do this and not the other isn't quite as asking why it isn't there. :) and yes I think that more type inference especially when it comes down to generics is useful.
Is there a compelling reason why they should devote limited resources to making that,
specifically, into a feature rather than all the other things they could be working on instead?
Yes because this is exactly how things work. I agreed to do something so I absolutely must prioritize everything I agree on to the next release over existing features but dunno that's something the LDT needs to decide I only asked a simple question, I didn't propose anything.
What are you trying to say here?
Exactly what I said. An unimplemented feature is something the team has decided to do but hasn't implemented yet. This is something that has not been decided. It is not a feature, unimplemented or otherwise.
Asking why it can do this and not the other isn't quite as asking why it isn't there.
The answer to "why it isn't there" is always the same: because nobody has built it. That may sound glib but it's quite literally true. (See above, re: limited resources.) There has to be a very good reason to spend time and effort designing, speccing, coding, testing, and documenting a new feature. Minus 100 points is a good article for understanding the team's perspective on it; I'd recommend familiarizing yourself with the principle it explains if you want to ask for new language features.
@HaloFour The entire language. If you define a constructor on a base class, you can use it on any of its descendants. The place it gets really useful, though, is when you start working with virtual constructors. You can call a virtual constructor with a metaclass reference, pass in the parameters, and get an instance of the class in question.
As I mentioned on the Github discussion, this was largely put in place to support form deserialization. The DFM (form data) files have class names in them, and the RTTI system has something functionally equivalent to a string->metaclass dictionary for all of the Component types used in your program. So you take your class name, get a metaclass from there, invoke the virtual constructor, and you have a Component-typed reference whose actual type is the class you wanted. Use RTTI to fill in the properties, then repeat recursively on all the child components until you have your whole form.
It kind of depends. If you're a software company with a budget, that hardly matters.
What does matter, though, is when your software company can't hire any devs because no one knows how to use your programming language because they weren't taught it in school and didn't pick it up as a hobby because there were plenty of free alternatives available.
Training someone on the basic syntax and semantics is easy, if they're already a competent programmer. Training someone to know and internalize the idiomatic patterns of the language and be familiar with its ecosystem? That takes years.
I'm not sure years is fair. Months, sure. Years gets you the equivalent of someone who reads all the language design meeting minutes, and you don't need that to be a competent programmer. But the cost of hiring someone is measured in months' salary anyway, and you're getting some level of value before they're fully competent