I wrote a function signatures, omitting parameter names and void return:
Void each(|nonexistent| f) //nonexistent is a type name rather than parameter name.
{
f(this)
}
The compiler is expected to complain. Is't a bug?
brianThu 1 Dec 2011
Promoted to ticket #1718 and assigned to brian
Yeah looks like we are falling back the Obj? inference there where we probably should require a real type.
brianSun 11 Dec 2011
Renamed from Check the Function signatures to Require func param types when used in slot signatures
brianSun 11 Dec 2011
Ticket resolved in 1.0.62
I pushed a fix for this so that function types used in slot signatures require that the parameter types are specified and only the parameter names may be optional. Interestingly I uncovered two in our own code base where this happened but it didn't cause any problems due to the way closure parameters get cast.
go4 Thu 1 Dec 2011
I wrote a function signatures, omitting parameter names and void return:
Void each(|nonexistent| f) //nonexistent is a type name rather than parameter name. { f(this) }The compiler is expected to complain. Is't a bug?
brian Thu 1 Dec 2011
Promoted to ticket #1718 and assigned to brian
Yeah looks like we are falling back the Obj? inference there where we probably should require a real type.
brian Sun 11 Dec 2011
Renamed from Check the Function signatures to Require func param types when used in slot signatures
brian Sun 11 Dec 2011
Ticket resolved in 1.0.62
I pushed a fix for this so that function types used in slot signatures require that the parameter types are specified and only the parameter names may be optional. Interestingly I uncovered two in our own code base where this happened but it didn't cause any problems due to the way closure parameters get cast.