Use of outer in default argument expressions #270

Closed
tombentley opened this Issue Apr 17, 2012 · 10 comments

Comments

Projects
None yet
4 participants
@tombentley
Member

tombentley commented Apr 17, 2012

The typechecker currently prohibits a default argument expression on an inner class from using outer:

class OC<T>(T t) {
    T m() {
        return t;
    }
    class IC(T t = outer.m()) {
    }
}
  1. Why?
  2. This limitation is not mentioned in the spec (AFAICT)
@quintesse

This comment has been minimized.

Show comment Hide comment
@quintesse

quintesse Apr 17, 2012

Member

Possibly because it on the agenda for M4, not sure.

Member

quintesse commented Apr 17, 2012

Possibly because it on the agenda for M4, not sure.

@ikasiuk

This comment has been minimized.

Show comment Hide comment
@ikasiuk

ikasiuk Apr 17, 2012

Member

Is the example correct? I think outer refers to the outer instance of OC at that point. The code seems to compile when you just write t = m(). But that's probably just a problem with the example - the question itself is valid.

Member

ikasiuk commented Apr 17, 2012

Is the example correct? I think outer refers to the outer instance of OC at that point. The code seems to compile when you just write t = m(). But that's probably just a problem with the example - the question itself is valid.

@tombentley

This comment has been minimized.

Show comment Hide comment
@tombentley

tombentley Apr 17, 2012

Member

@quintesse The error message ("reference to outer from default argument expression") suggests its something deeper than not being supported yet.

@ikasiuk Yes it will work without the outer (by closure), but if IC has a m() you'd have to disambiguate with outer.

Member

tombentley commented Apr 17, 2012

@quintesse The error message ("reference to outer from default argument expression") suggests its something deeper than not being supported yet.

@ikasiuk Yes it will work without the outer (by closure), but if IC has a m() you'd have to disambiguate with outer.

@quintesse

This comment has been minimized.

Show comment Hide comment
@quintesse

quintesse Apr 17, 2012

Member

Why would it suggest something deeper? Gavin often makes the typechecker throw errors for features that are not finished yet, right? In this case I'm pretty sure it's because we don't support references to outer from within defaulted initializer parameters yet.

Member

quintesse commented Apr 17, 2012

Why would it suggest something deeper? Gavin often makes the typechecker throw errors for features that are not finished yet, right? In this case I'm pretty sure it's because we don't support references to outer from within defaulted initializer parameters yet.

@tombentley

This comment has been minimized.

Show comment Hide comment
@tombentley

tombentley Apr 17, 2012

Member

Well, normally those errors are of the form "... is not yet supported".

Member

tombentley commented Apr 17, 2012

Well, normally those errors are of the form "... is not yet supported".

@quintesse

This comment has been minimized.

Show comment Hide comment
@quintesse

quintesse Apr 17, 2012

Member

What is the exact message?

Member

quintesse commented Apr 17, 2012

What is the exact message?

@tombentley

This comment has been minimized.

Show comment Hide comment
@tombentley

tombentley Apr 17, 2012

Member
Whatever.ceylon:5: reference to outer from default argument expression
    class IC(T t = outer.m()) {
                   ^
Member

tombentley commented Apr 17, 2012

Whatever.ceylon:5: reference to outer from default argument expression
    class IC(T t = outer.m()) {
                   ^
@quintesse

This comment has been minimized.

Show comment Hide comment
@quintesse

quintesse Apr 17, 2012

Member

Personally I think he just forgot to add the "not yet supported", I'm pretty sure I remember when he added this when I made the first support of default expressions and there was something that didn't work and we couldn't figure out an easy way to fix it so he decided just to prohibit it for now. this worked but outer was more difficult somehow.

Member

quintesse commented Apr 17, 2012

Personally I think he just forgot to add the "not yet supported", I'm pretty sure I remember when he added this when I made the first support of default expressions and there was something that didn't work and we couldn't figure out an easy way to fix it so he decided just to prohibit it for now. this worked but outer was more difficult somehow.

@ikasiuk

This comment has been minimized.

Show comment Hide comment
@ikasiuk

ikasiuk Apr 18, 2012

Member

Yes it will work without the outer (by closure), but if IC has a m() you'd have to disambiguate with outer.

Ah, you are right. Seems a bit strange though that the scope at that point is already the scope of the inner type.

Member

ikasiuk commented Apr 18, 2012

Yes it will work without the outer (by closure), but if IC has a m() you'd have to disambiguate with outer.

Ah, you are right. Seems a bit strange though that the scope at that point is already the scope of the inner type.

@gavinking

This comment has been minimized.

Show comment Hide comment
@gavinking

gavinking Apr 23, 2012

Member

The outer keyword is not yet supported, as far as I remember.

Member

gavinking commented Apr 23, 2012

The outer keyword is not yet supported, as far as I remember.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment