gafter on master
Propose Feb 11 agenda (#2187) (compare)
JToken
defines an explicit cast to string?
, see here. Since invoking that explicit operator on a JToken
might result in a null string, the compiler's complaining that you're casting it to a non-nullable string
Is there any reason the compiler can infer the type of TRequest
in the following case:
public static async Task AddRow<TRequest>(int tableId, TRequest request)
When calling the method like AddRow(..., new MyRequestObject())
But not partially when there is more than one type parameter like in this this?
public static async Task<TResponse> AddRow<TResponse,TRequest>(int tableId, TRequest request)
The first method does not exist so there is no ambiguity so why can't I just do AddRow<MyResponseObject>(..., new MyRequestObject())
?
@masonwheeler
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.