Inconsistent symbol when explaining types

On Sun, Oct 18, 2009 at 1:33 PM, Christos KK Loverdos
wrote:
> Hi all,
>
> I noticed that when explaining types with -explaintypes, then the symbol <
> instead of the usual <: is used for subtyping.
>
> I propose to change that to <: for consistency. I have tracked the change at
> line 534 of Types.scala, so that explain("<", isSubType, this, that) becomes
> explain("<:", isSubType, this, that).
>
> If this is OK, since my compiler-fu is very low and innocent-looking things
> are sometimes the most dangerous, I am asking if the change above is safe.
>
> I could commit the change myself, open a ticket just to have this trac(k)ed
> and backport it to 2.7[1] for uniformity.
>
No need to do that. I just did the change in my copy of Types.scala. I
don't think this is a case for backporting though.

Cheers

On Oct 18, 2009, at 22:19, martin odersky wrote:

> On Sun, Oct 18, 2009 at 1:33 PM, Christos KK Loverdos
> wrote:
>> Hi all,
>>
>> I noticed that when explaining types with -explaintypes, then the
>> symbol <
>> instead of the usual <: is used for subtyping.
>>
>> I propose to change that to <: for consistency. I have tracked the
>> change at
>> line 534 of Types.scala, so that explain("<", isSubType, this,
>> that) becomes
>> explain("<:", isSubType, this, that).
>>
>> If this is OK, since my compiler-fu is very low and innocent-
>> looking things
>> are sometimes the most dangerous, I am asking if the change above
>> is safe.
>>
>> I could commit the change myself, open a ticket just to have this
>> trac(k)ed
>> and backport it to 2.7[1] for uniformity.
>>
> No need to do that. I just did the change in my copy of Types.scala. I
> don't think this is a case for backporting though.
>
OK, thank you Martin.

I do not recall the requirements for backporting right now, but I
stumbled across that when explaining something in the book, whose code
is mostly written under 2.7, so I thought it would be nice to have the
change back to 2.7 as well. Just for uniformity.