This test case:

using fwt
using fwt::RichTextStyle as Style

class bug
{
  Void test()
  {
    defaultStyle := RichTextStyle
  }
}

generates this compiler walkback:

sys::NullErr: Coerce to non-null
  fan.sys.NullErr.makeCoerce (NullErr.java:38)
  compiler::Parser.simpleType (Parser.fan:2143)
  compiler::Parser.ctype (Parser.fan:2052)
  compiler::Parser.tryType (Parser.fan:2026)
  compiler::Parser.termBaseExpr (Parser.fan:1500)
  compiler::Parser.termExpr (Parser.fan:1479)
  compiler::Parser.termExpr (Parser.fan)
  compiler::Parser.unaryExpr (Parser.fan:1452)
  compiler::Parser.parenExpr (Parser.fan:1381)
  compiler::Parser.multiplicativeExpr (Parser.fan:1366)
  compiler::Parser.additiveExpr (Parser.fan:1354)
  compiler::Parser.shiftExpr (Parser.fan:1342)
  compiler::Parser.bitAndExpr (Parser.fan:1330)
  compiler::Parser.bitOrExpr (Parser.fan:1318)
  compiler::Parser.rangeExpr (Parser.fan:1300)
  compiler::Parser.elvisExpr (Parser.fan:1283)
  compiler::Parser.relationalExpr (Parser.fan:1252)
  compiler::Parser.equalityExpr (Parser.fan:1220)
  compiler::Parser.condAndExpr (Parser.fan:1200)
  compiler::Parser.condOrExpr (Parser.fan:1180)
  compiler::Parser.ternary (Parser.fan:1161)
  More...

Promoted to ticket #545 and assigned to brian

Ticket resolved in 1.0.42

I think the proper behavior here is that the using as statements trumps the using statement to take the identifier RichTextStyle out of the imported namespace. So now it correctly reports a compiler error.

I think I agree; this came up when I went back to a file, having forgot I'd put in that using as. So, in this case at least, I needed the compiler to remind me.

I assume you can still get at the original name with the pod qualifier, as fwt::RichTextStyle? Although I don't know why you'd need to.

I assume you can still get at the original name with the pod qualifier, as fwt::RichTextStyle? Although I don't know why you'd need to.

Yeap - I added that to the regression test just to make sure.