8 Dec 2008 00:03
Re: Removing necessity to "overide" type aliases?
On Wed, Dec 3, 2008 at 3:42 AM, Lex Spoon <lex-2XCpF38ZseRg9hUCZPvPmw@public.gmane.org> wrote:
yes, but is all this worth an extra rule in the spec? I mean, who would write such a thing?
Cheers
-- Martin
Oh, Id is the identity type constructor! I missed that, and thought it was a random parameterized type.
On Dec 2, 2008, at 4:17 PM, Geoffrey Alan Washburn wrote:Lex Spoon wrote:Neither Id[Int] is by definition Int, therefore it is perfectly sound.
On Dec 2, 2008, at 10:30 AM, Geoffrey Alan Washburn wrote:type Id[X] = XI'm amazed that the above works at all! Is B still considered a
trait A { type T = Int }
trait B extends A { override type T = Id[Int] }
that the user need not write "override"? Assuming everything else
in the language works as expected, you can never change T to be
something else so really writing "override" is redundant. Of
course, I would like this for the entirely selfish reason that I do
not have to explain this minor semantic difference between Scala
Classic and Scala proper.
subtype of A? Or is A restricted from taking advantage of T being Int ?
I see. Yes, that does make it seem silly to have to write "override".I guess my claim is that you cannot "accidentally" override a type definition. For reasons of type soundness, you can only override a type definition with a type that is equivalent to the one originally defined. So all that happens when a user "accidentally" overrides a type definition is that they just redefine exactly the same type they had before. If you can't ever change the type, claiming you are overriding it is kind of vacuous.
yes, but is all this worth an extra rule in the spec? I mean, who would write such a thing?
Cheers
-- Martin
RSS Feed