Would it be reasonable to support type inference on literals? For example:
class Whatever {
Int[] ints := [,] // Expected type is Int[] so that's what it is.
Void doSomething(Str:Str props) {
// ...
}
Void main() {
doSomething([:]) // Same idea here, but the param type leads to the inference.
Float f := 1 // Interpreted by compiler to be a float literal.
}
}
The idea is that once it "becomes an object", the type doesn't change of course. (No implicit type conversion.) The idea is that as a literal, it usually means a particular type, but the compiler can it interpret it differently in different contexts before it "becomes an object".
I'm not convinced this is a good idea. Just a thought that could possibly make some things easier. This behavior might be more intuitive in some cases but perhaps more complicated in others.
brianThu 3 Jul 2008
I think type inference should always be based on expressions, not tied into local variable declarations or calling paramters. That seems a lot more flexible with regards to how the feature interoperates with other aspects of the language.
That said, I can see where this is coming from - because that is pretty much exactly what I proposed myself as the way to do type inference for closures used as method arguments (you've just proposed making it more general purpose).
tompalmer Sun 29 Jun 2008
Would it be reasonable to support type inference on literals? For example:
class Whatever { Int[] ints := [,] // Expected type is Int[] so that's what it is. Void doSomething(Str:Str props) { // ... } Void main() { doSomething([:]) // Same idea here, but the param type leads to the inference. Float f := 1 // Interpreted by compiler to be a float literal. } }The idea is that once it "becomes an object", the type doesn't change of course. (No implicit type conversion.) The idea is that as a literal, it usually means a particular type, but the compiler can it interpret it differently in different contexts before it "becomes an object".
I'm not convinced this is a good idea. Just a thought that could possibly make some things easier. This behavior might be more intuitive in some cases but perhaps more complicated in others.
brian Thu 3 Jul 2008
I think type inference should always be based on expressions, not tied into local variable declarations or calling paramters. That seems a lot more flexible with regards to how the feature interoperates with other aspects of the language.
That said, I can see where this is coming from - because that is pretty much exactly what I proposed myself as the way to do type inference for closures used as method arguments (you've just proposed making it more general purpose).