!actorable functions MUST use @actor to become messages; @escaping is… #665
Conversation
|
I think this is very much "better" than the current status which was "opt out" (by __ prefixing function names) as it would completely break if the actorable also had to conform to some other protocol. |
|
|
||
| extension GeneratedActor.Messages.GreetingsService { | ||
| // TODO: Check with Swift team which style of discriminator to aim for | ||
| public enum DiscriminatorKeys: String, Decodable { |
| /// Initial entry point for accepting a new connection; Potentially allocates new handshake state machine. | ||
| /// - parameter inboundChannel: the inbound connection channel that the other node has opened and is offering its handshake on, | ||
| /// (as opposed to the channel which we may have opened when we first extended a handshake to that node which would be stored in `state`) | ||
| /// (as opposed to the channel which we may have opened when w e first extended a handshake to that node which would be stored in `state`) |
There was a problem hiding this comment.
| /// (as opposed to the channel which we may have opened when w e first extended a handshake to that node which would be stored in `state`) | |
| /// (as opposed to the channel which we may have opened when we first extended a handshake to that node which would be stored in `state`) |
| // TODO: if receiveTerminated ot receiveSignal etc, FORCE them to be marked @actor | ||
|
|
||
| if self.settings.verbose { | ||
| print(" Skip [func \(name)]... (not marked as `@actor func`)") |
There was a problem hiding this comment.
not marked as
@actor func
Users need to mark with // @actor, not just @actor, right?
There was a problem hiding this comment.
Right i guess I’ll rephrase to “comment must include @Actor”?
There was a problem hiding this comment.
It would be better to include the exact syntax I think
There was a problem hiding this comment.
Ok, will do :) We can print a copy-pasteable signature actually perhaps 🤔
|
Now also with enforcing that lifecycle functions MUST be @Actor since it kind of makes sense. |
|
Updated docs to talk about this as well as some codegen better "assistance" when you get it wrong. |
|
Failure is the flakyness that we're addressing in #654 |
|
(merging to continue work on top of this towards generics -- please post merge review if you're interested / have opinions about this) |
2 participants
"Actor (message) functions" MUST now mark themselfes as @Actor
This also paves the way forward to what we really want here: function wrappers.
Motivation:
previously we lacked any control over what is generated and we'd generate messages for any method on an actorable except if it was __ prefixed.
This does not work well in real world where actorables may conform to various protocols and have to implement them.
It is NOT enough to just rely on public/internal/private because we may need to have "private messages" etc.
This solves this FIXME as well:
Modifications:
@actorcomment in order to be source generated as messages@escapingis treated -- we are able to have closures in local messages now (even tho yes its a bad idea but sometimes useful if the closure is pure)