A case that I've come across countless times is this scenario:
class Main
{
Int[] myInts := [,]
Void main()
{
echo(myInts.typeof)
}
}
As is evident from the output, the myInts array is typed as an Obj?[] instead of an Int[]. I know that it makes sense to the compiler, but it seems quirky from a programmer's perspective and the alternative isn't DRY.
I'm wondering if we can special-case the List and Map types to be retyped automatically to the LHS type during same-line initialization. So that the above code is treated equivalently to this:
class Main
{
Int[] myInts := Int[,]
Void main()
{
echo(myInts.typeof)
}
}
This would apply only to same-line initialization and only to parametrized types. Maybe that includes functions too, but usually, you'd just spell it "method" instead.
ivanFri 19 Feb 2010
I face this issue constantly, especially this creates problems with Fan deserialization or list comparison. So right now I really avoid using constructions like [,] and [:] even in cases when it is safe. I posted a bug some time ago, but it was canceled - http://fantom.org/sidewalk/topic/739
tacticsFri 19 Feb 2010
Yeah. I remember that issue. I think it was canceled because it isn't technically a bug.
It's still a pain in the butt (one of the few places that Fantom is), and I'd like to see if there's anyway we can get rid of the redundancy it creates.
brianFri 19 Feb 2010
For normal local variables you can use type inference.
So this is really restricted to a type inference for fields. A while back we debated using type inference for fields, and decided not to do it. And I think that is still correct, that a field should have a declared type.
But if there is widespread support for it, I think I could support a special type inference for fields just for [,] and [:] that inferred the type from the LHS (everything is RHS inference).
tacticsFri 19 Feb 2010
Yes. For local vars, it isn't a problem. It's just when you have slots being initialized.
I'm all for adding LHS inference for this case if it means I don't have to type as much :)
brianWed 24 Feb 2010
Promoted to ticket #986 and assigned to brian
Will change the semantics of field intializers so that [,] and [:] are inferred to be typed based on LHS of the field declaration. This is sort of similar to Java's new diamond operator. This feature will not apply to local variables where normal type inference may be used.
brianWed 24 Feb 2010
Renamed from Automated retyping on List and Map during initialization? to Field initializer List and Map type inference
brianTue 23 Mar 2010
Ticket resolved in 1.0.52
I got this feature working. Anytime you have a list or map literal as a field initializer without an explicit type signature, it automatically infers its type from the field's declared type.
This program will now print "sys::Str[]":
class Foo
{
Str[] x := [,]
Void main() { echo(x.typeof) }
}
This should be a very welcome feature to anyone writing a lot of Fantom code (it will simplify a ton of my own code).
tacticsTue 23 Mar 2010
Awesome 8`)
lbertrandTue 23 Mar 2010
Thank you so much for this... A very welcome improvement!
tactics Fri 19 Feb 2010
A case that I've come across countless times is this scenario:
As is evident from the output, the
myInts
array is typed as anObj?[]
instead of anInt[]
. I know that it makes sense to the compiler, but it seems quirky from a programmer's perspective and the alternative isn't DRY.I'm wondering if we can special-case the
List
andMap
types to be retyped automatically to the LHS type during same-line initialization. So that the above code is treated equivalently to this:This would apply only to same-line initialization and only to parametrized types. Maybe that includes functions too, but usually, you'd just spell it "method" instead.
ivan Fri 19 Feb 2010
I face this issue constantly, especially this creates problems with Fan deserialization or list comparison. So right now I really avoid using constructions like
[,]
and[:]
even in cases when it is safe. I posted a bug some time ago, but it was canceled - http://fantom.org/sidewalk/topic/739tactics Fri 19 Feb 2010
Yeah. I remember that issue. I think it was canceled because it isn't technically a bug.
It's still a pain in the butt (one of the few places that Fantom is), and I'd like to see if there's anyway we can get rid of the redundancy it creates.
brian Fri 19 Feb 2010
For normal local variables you can use type inference.
So this is really restricted to a type inference for fields. A while back we debated using type inference for fields, and decided not to do it. And I think that is still correct, that a field should have a declared type.
But if there is widespread support for it, I think I could support a special type inference for fields just for
[,]
and[:]
that inferred the type from the LHS (everything is RHS inference).tactics Fri 19 Feb 2010
Yes. For local vars, it isn't a problem. It's just when you have slots being initialized.
I'm all for adding LHS inference for this case if it means I don't have to type as much :)
brian Wed 24 Feb 2010
Promoted to ticket #986 and assigned to brian
Will change the semantics of field intializers so that
[,]
and[:]
are inferred to be typed based on LHS of the field declaration. This is sort of similar to Java's new diamond operator. This feature will not apply to local variables where normal type inference may be used.brian Wed 24 Feb 2010
Renamed from Automated retyping on List and Map during initialization? to Field initializer List and Map type inference
brian Tue 23 Mar 2010
Ticket resolved in 1.0.52
I got this feature working. Anytime you have a list or map literal as a field initializer without an explicit type signature, it automatically infers its type from the field's declared type.
This program will now print "sys::Str[]":
This should be a very welcome feature to anyone writing a lot of Fantom code (it will simplify a ton of my own code).
tactics Tue 23 Mar 2010
Awesome 8`)
lbertrand Tue 23 Mar 2010
Thank you so much for this... A very welcome improvement!
KevinKelley Tue 23 Mar 2010
Oh, yeah. All good things, this batch of fixes.
qualidafial Wed 24 Mar 2010
Very nice!