actor class sugar is a footgun

[crusso]

I think our sugar that makes public functions of actors shared is a potential footgun (@osa1 shot himself already).

For example, these two very similar programs have very different semantics:

import Prim "mo:prim";
actor a {
    let bound:Int = 100000;
    func Loop1(n:Int) { // note private, so local and synchronous
        if (n >= bound) {
            Prim.debugPrint "done 1";
            return;
        };
        Loop1(n+1);
    };
    public func test_loop1() : async () {
      Loop1(0); // synchronously wait for the loop to complete
    };
};

import Prim "mo:prim";
actor a {
    let bound:Int = 100000;
    public func Loop1(n:Int) { // note public, so asynchronous and oneway
        if (n >= bound) {
            Prim.debugPrint "done 1";
            return;
        };
        Loop1(n+1);
    };
    public func test_loop1() : async () {
      Loop1(0); // returns immediately after firing off a oneway
    };
};

[osa1]

Wow, changing visibility of a function changing its sync/async properties is really surprising. What was the motivation for this? I think it might be good to remove this.

[rossberg]

Nice example. Agreed this is bad. Just to double-check: you can only run into this using oneway methods, correct? Because otherwise you'd at least get a type error?

So should we drop the sugar and require everybody to write shared everywhere? Kind of annoying for toy examples, but maybe not a big deal for "real" programs? Should we also drop the equivalent sugar from types? Don't think it can cause a problem there, but I suppose consistency would suggest it. But might be more annoying in practice.

[crusso]

I'm a bit loathe to change this so late in the game.

What if we just warn on a public oneway that isn't explicitly shared?