Improve error reporting: Accessing protected members within async blocks.

[isaacabraham]

What

In a class implementation, trying to access a protected base class member within an async block won't compile: -

    member __.Foo() = async { return base.Ok()  } // Pop

The error is: -
The member or object constructor 'Ok' is not accessible. Private members may only be accessed from within the declaring type. Protected members may only be accessed from an extending type and cannot be accessed from inner lambda expressions.

Why

My first question - although slightly beside the point - would be, why does this error occur (from a language point of view)?
My concern with this error is that: -

• It's somewhat unclear what it means. Yes, I get it - but beginners will not understand that an async block might cause continuations etc. etc. which in turn are therefore forbidden.
• It provides no suggestion to work around this, when there's a perfectly legitimate one: -

    member __.Ok() = base.Ok()
    member this.Foo() = async { return this.Ok()  } // now compiles

How

Quick win

Improve the error so when when within a CE, the error says: -
The member or object constructor 'Ok' is not accessible. Private members may only be accessed from within the declaring type. Protected members may only be accessed from an extending type and cannot be accessed from within a computation expression such as Async.

Slightly more betterer win

Improve the error so when when within a CE, the error says: -
The member or object constructor 'Ok' is not accessible. Private members may only be accessed from within the declaring type. Protected members may only be accessed from an extending type and cannot be accessed from within a computation expression such as Async. Consider creating a member in this type which explicitly calls to the protected member, and call that member from this code point instead.

Most bestest win

The code fixes are so menial and obvious, it leads to the question: why not have the compiler do it for us? The best solution to this would simply be to eliminate this (if possible, of course) by generating a member that does the delegation, thus eliminating this error completely.

[KevinRansom]

Yes I think most bestest win is indeed the approach to take.

[dsyme]

The underlying problem is the same with protected calls from lambda expressions: F# doesn't generate lambda closure classes into the class being defined, but rather into a separate ImplementationDetails class.

This is mostly because - in the tradition of other funcitonal language implemtnations - we always wanted to keep the flexibility to radically change the compilation strategy for lambdas if necessary - either through inlining, or defunctionalization, or direct calls or whatever. So we knowingly placed a limitation that protected calls just couldn't occur in lambdas.

Nowadays we have good ways in the compiler to detect if protected calls are being made in a block of code. We should probably just now adjust the compiler to emit closure classes as nested classes of the class being generated, at least for those containing protected calls. It's probably a relatively simple change in IlxGen.fs in the stuff that generates the identity for closure classes.

[smoothdeveloper]

would generating delegating internal members be simpler (and less IL bloat) than emitting closure classes?

[isaacabraham]

Or even private? I suppose it's also about maintain state of the closure as well though.

[isaacabraham]

@KevinRansom @dsyme would it be worth as a quick win updating the error message for e.g. F# vNext and then doing the "most bestest" solution as something further down the line? Would you be ok to accept a PR that changed the error text as per above?

[dsyme]

Would you be ok to accept a PR that changed the error text as per above?

Yes! :) though you probably want

The member or object constructor '%s' is not accessible. Private members may only be accessed from within the declaring type. Protected members may only be accessed from an extending type and cannot be accessed from inner lambda expressions, object expressions, computation expressions or async expressions. If '%s' is a protected member, consider using an auxiliary private member that calls it.

[isaacabraham]

@KevinRansom could we actually leave this open, for the third variant which is more complex but would definitely be beneficial.