Open ewoolsey opened 2 months ago
My first impression is that this is an API nightmare, since defaulting to maybe means now everything that doesn't want to be maybe has to be explicitly marked.
Like, you've just moved the verbosity somewhere else, and effectively required it to be used more often.
now everything that doesn't want to be maybe has to be explicitly marked.
This isn't how I was envisioning it. You wouldn't have to declare non-async functions as the compiler would just infer them. For example:
fn foo(){}
would be automatically inferred to be !async fn foo() -> ()
async fn foo(){
bar().await
}
would be automatically inferred to be async fn foo() -> ()
fn foo(){
if ?async {
bar().await
}
}
would be automatically inferred to be ?async fn foo() -> ()
@clarfonthey The point of my proposal here is to virtually eliminate adding extra syntax to function signatures and let the compiler figure it out.
Oh, that makes more sense, although this would be unprecedented in the language, at least for regular functions, since the reason why they require annotations is purely for API documentation purposes and not because they can't infer them.
I can definitely see the argument of doing this for closures, though. Although I'm not exactly sure how useful maybe-async closures are in general.
One common complaint I see about the
keyword-generics-innitiative
is that the syntax can be quite verbose. The core idea I have is to essentially treat all unmarked keyword functions asmaybe keyword
. A solution I've been exploring in my head looks something like this:Awaiting a function which doesn't contain an `?async' block/section would result in a warning. Conversely, not awaiting a function which does contain an async block/section while inside an async context would also emit a warning. I imagine this style of implementation should be fully backwards compatible.
Perhaps there's something I'm missing here, but declaring a function signature like
or
seems superfluous.
Currently, the compiler can tell if a
const
fn is valid. So it would seem to me that it should also be able to validate if calling unmarked (maybe const) functions from within a const function is valid. I'll give an example:This example would compile because the compiler could check that
bar_maybe_const
has a valid const implementationThis example would error because the compiler could check that
bar_maybe_const
has no valid const implementationThis is just something that's been spinning in my head for a while and there's a good chance I'm not seeing the whole picture here. But I'd love to get your thoughts/opinions on this.