Why def is not a valid export prefix?

[mwisnicki]

Why exporting def is not allowed?

trait Foo:
  def bar: Bar
  export bar.*

Fails with

(Foo.this.bar : => Bar) is not a valid export prefix, since it is not an immutable path

I can certainly do this manually so why the restriction?

[mwisnicki]

Of course I’d expect all embedded vals to be exported as defs in such case.
Or at least an error on any specific members that can’t be exported.

[ysthakur]

Because members of bar could change every time it’s called. This doesn’t sound like a great idea if you don’t have explicit nulls enabled. Also, every time you want to access something from there, you’d have to call bar again. It’s better to just export bar and let the user memoize it or do whatever they want to do with it.

[mwisnicki]

I don’t see how members can change on call. Perhaps you meant the values of members could change but there’s nothing wrong with that. They could change when accessed through val as well.

[soronpo]

Maybe in the future it will. See Martin’s comment here:

Proposed Changes and Restrictions For Implicit Conversions

It can be generally allowed for exports but not for imports. It’s a question of evaluation order. Say you have import f(x).a ... a + a when is f(x) evaluated? I believe it would have to be evaluated at the point where the import appears, so the code would rewrite to val $temp = f(x) ... $temp.a + $temp.a The alternative semantics would rewrite at the point of access, i.e.: ... f(x).a + f(x).a That would not only surprising and potentially costly. It would not work at all if we import a ty…

[mwisnicki]

Thanks for the link, very helpful. I was in fact going to use inline def so the rewrite at the point of access wouldn’t be surprising at all and in fact desired.

Hopefully it will be added one day.