Possible alternative to tilde/`?` using bound-like syntax

[tgross35]

Opinion

I stumbled upon this repo as a complete outsider, and one of the things that stood out to me was the syntax. Taking an example from the book:

~async fn async_find<I>(
    iter: impl ~async Iterator<Item = I>,
    closure: impl ~async FnMut(&I) -> bool,
) -> Option<I>

Or (I think) its equivilant where

~async fn try async_find<It, Cl, I>(iter: It, closure: It) -> Option<I>
where:
    It: ~async Iterator<Item = I>,
    Cl: ~async FnMut(&I) -> bool

I find it a bit difficult to read:

• To somebody new to the syntax, there's nothing that really indicates the "asyncness" of the function is related to the asyncness of the iterator and closure.
• ~ is a destructor in c++, bitwise NOT in C and some others, and used to be a heap operator in former Rust. Its usage for "if and only if" relationships is foreign to me and not super intuitive (maybe some other languages use something similar, I'm not aware)
• ~ on its own is kind of a weird character, it's the same width as a letter but sort of visually floats. So it means that if some functions on a page are ~async and some aren't, the fn keywords misalign just enough to be mildly annoying:

async fn foo(F: impl async Iterator) ...

~async fn bar(F: impl ~async Iterator) ...

async fn some_other_foo(F: impl async Iterator) ...

The last thing is a very subjective visual nitpicks, but I think in general this syntax has a potential to get a bit messy (are combinations like ~const ~async eventually expected?)

Suggestion

I think that there's likely a way to leverage trait bound syntax to express these things, in a way that is already familiar. As a simple example:

fn foo<F: FnOnce(i32)>(f: F)
where
    fn: const if F: const,
{ /* ... */ }

And an example with multiple bounds with more complex relationships:

fn foo_finder<It, Cl, I>(iter: It, closure: It) -> Option<I>
where
    It: Iterator<Item = I>,
    Cl: FnMut(&I) -> bool,
    fn: async if It: async + Cl: async,
    fn: const if Cl: const,
    fn: !panics if It: !panics + F2: !panics
{ /* ... */ }

Advantages as I see them:

• I find this to be much more expressive: something like fn: async if It: async + Cl: async, says almost perfectly "this function is async if both iterator It and closure Cl are async".
• There's no problem adding >1 keyword bound (async and const, as well as the fake !panics / !panicking here), and it still looks visually consistent
• More nuanced trait bounds are possible, like fn: async if Cl: const or fn: async if I: Sync. I can't really visualize a use case for it, but at least it's possible.
• This could likely be leveraged in some way with traits / associated functions. fn: const if Self::get_or_init: const
• It's more familiar and doesn't look like something from a different programming language, and it's no problem to add >1 keyword bound. We already express both trait bounds and lifetimes in this way, why not just extend it to express keyword things?

A downside is that it wouldn't be as simple to express this using the inline syntax with impl as shown above.

Anyway, not sure if something like this has been discussed or if there's a specific reason it wouldn't work, but just wanted to share my 2¢.

[tgross35]

At first I was thinking that in my example, not having const fn / async fn visible up front was a downside. After thinking about it for a bit though, I think it might actually be a plus: the functions are non-const by default (as most functions that you could pass to it are also non-const), but there are special conditions that make it const.

[tgross35]

Relevant Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/328082-t-lang.2Fkeyword-generics/topic/~const.20desugaring

It was brought up there that there needs to be a way to specify bounds on a specific trait, rather than on a type. Possible solution:

fn foo<Closure, ItemTy>(closure: Closure) -> Option<ItemTy>
where
    Closure: FnMut(&ItemTy) -> bool, // const bound is here
    Closure: SomeOtherTrait, // but not here
    fn: const if <Closure as FnMut>: const,
{ /* ... */ }

This extra bound specification would only be needed if type Closure has >1 trait bound. The style would be quite consistent with the existing syntax of needing to narrow function calls like <SomeType as SomeTrait>:foo when there are multiple traits provide a function named foo.

[obsgolem]

I just wanted to hop in and note that this idea is kind of like treating effects as a special kind of marker trait. The proposed syntax above could be thought of as syntactic sugar for something that could be written like this:

impl<F, T> const for fn foo 
where 
       F: FnMut(&T) -> bool,
       F: const

It was brought up there that there needs to be a way to specify bounds on a specific trait, rather than on a type. Possible solution:

fn foo<Closure, ItemTy>(closure: Closure) -> Option<ItemTy>
where
    Closure: FnMut(&ItemTy) -> bool, // const bound is here
    Closure: SomeOtherTrait, // but not here
    fn: const if <Closure as FnMut>: const,
{ /* ... */ }

Continuing my line of thought above, this need is then like saying that const is a "trait for traits". The proposed syntax could then be the way of creating higher order trait bounds.

[tgross35]

Continuing my line of thought above, this need is then like saying that const is a "trait for traits"

That's exactly the way I see it. They aren't the type: Trait bounds we currently have, but they similarly bind a function or trait to a set of requirements. A const function is required to not call non-const functions, an async function must return a future, !panicking functions can't call functions that may panic, and if user-defined effects are ever possible then they'd likely be similar.

[Sp00ph]

I like the idea of !panics and !unwinds constraints (where !panics implies !unwinds). I feel like it could make unsafe code a lot simpler if you don't need to worry about user provided types unwinding because you wouldn't need as many drop guards and such. If you really wanted to you could even make a !unwinds function wrapper that aborts if the provided function panics (sort of like how noexcept behaves in C++).

[jssblck]

Coming here from the recent WG report.

Please please do not stick with the ?async and friends syntax. In a future where library maintainers can make their functions optionally async, we will, and many functions (maybe even most functions) will become littered with these bounds.

This means that picking something that isn't jarring is critical.

I really don't want to have to read Rust code that looks like this (from the linked report):

trait ?const ?async Read {
    ?const ?async fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    ?const ?async fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { .. }
}

/// Read from a reader into a string.
?const ?async fn read_to_string(reader: &mut impl ?const ?async Read) -> io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

Not only is it very noisy, it's also very ugly; Rust code syntax is kind of already a meme (although I think it's beautiful in its own way), and a change like this would lean into that really hard. Code is read far more often than written, and making code easily legible is key to maintainable software. By mixing upper case (?) with lower-case identifiers in front of the function, IMO the function becomes more difficult to parse and therefore less legible. Even with the older ~ syntax it still felt very noisy and off putting.

I do like the ?effect/.do proposed solution to this, but it's important to recognize that not all functions will be valid for all effects.

For example, this is exactly the kind of thing I'd personally write:

/// We want to explicitly state that this can't panic, so we can't use `?effect` to do it generically.
///
/// Alternately, assume some keyword exists which we don't want to support,
/// or we have more keywords we don't want to support than ones that we do,
/// or we want to support all of today's keywords but not all future keywords forever, etc.
/// The point is to illustrate what it looks like with a bunch of keywords.
trait ?const ?async !panic !unwind Read {
    ?const ?async !panic !unwind fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    ?const ?async !panic !unwind fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { .. }
}

/// Read from a reader into a string.
?const ?async !panic !unwind fn read_to_string(reader: &mut impl ?const ?async !panic !unwind Read) -> io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

This reminds me of fused-effects in a really negative way.

---

Now, having complained, in regards to this specific issue, I think this (or something like it) is a really good idea.
By putting these constraints in the where block, it reduces the apparently noise by moving into a spot where real estate is less premium and mixing upper/lowercase identifiers (or other odd mixes) already exists. Or in other words, "where is already really noisy, so making it more noisy at least limits the blast radius".

If this issue were implemented, the function above becomes something like:

fn read_to_string(reader: &mut R) -> std::io::Result<String>
where
  R: Read,
  fn: async if R: async,
  fn: const if R: const,
  fn: !panic + !unwind,
{
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

Which is much more tractable.

Overall, I love the idea of keyword generics, but I implore the WG to reconsider this syntax and deeply consider what'd be the best syntax for a version of Rust where these bounds were on the vast majority of functions, because I think that's where we're headed.

[Sp00ph]

If this issue were implemented, the function above becomes something like:

fn read_to_string(reader: &mut R) -> std::io::Result<String>
where
  R: Read,
  fn: async if R: async,
  fn: const if R: const,
  fn: !panic + !unwind,
{
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

The !panic + !unwind constraints probably couldn't be satisfied for this function specifically (What if the reader panics? Or what if it produces > isize::MAX bytes and the string allocation panics?). But yes I agree, the where bounds look much more pleasant and readable to me too.

[satvikpendem]

I agree regarding the current ~/? syntax being quite annoying to parse and read through. The above example

?const ?async !panic !unwind fn read_to_string(reader: &mut impl ?const ?async !panic !unwind Read) -> io::Result<String>

does not even really tell me what the actual function is about until half-way through the function signature, and then there is another long string of terms to figure out exactly what the function parameter is.

In contrast, with the below

fn read_to_string(reader: &mut R) -> std::io::Result<String>
where
  R: Read,
  fn: async if R: async,
  fn: const if R: const,
  fn: !panic + !unwind,
{
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

I can tell exactly what is happening at a high overview, that read_to_string takes a reader with some properties that I can then look at in a further in the where clause.

If I were in a large codebase with many such functions in the ~/? syntax, it would be difficult for me to parse through and figure out which function I'm looking for.

If fn looks too much like a type or otherwise seems like a "magical" variable, another user on the /r/rust thread mentioned having effects even be after the where clause via the effect keyword:

fn foo<F, T>(closure: F) -> Option<T>
where 
    F: FnMut(&T) -> bool,
effect 
    const if F: const,
    ?async,
{ /* ... */ }

And here we can use the ? prefix to signify "maybe" and also have the ! prefix to signify not.

Personally I like this last syntax the best since it is much more readable while still allowing the aforementioned prefixes and also not making fn seem somewhat magical. If we have more types of effects in the future, maybe even a full-blown effects system, it is easy enough to add them to the effect list.

[utkarshgupta137]

What about allowing a "generic-like" syntax?
For eg:

trait<R: ?const ?async !panic !unwind> Read<R> {
    fn<R> read(&mut self, buf: &mut [u8]) -> io::Result<usize>;
    fn<R> read_to_string(&mut self, buf: &mut String) -> io::Result<usize> { .. }
}

fn<R: ?const ?async !panic !unwind> read_to_string(reader: &mut impl Read<R>) -> io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

fn<R> foo<F, T>(closure: F) -> Option<T>
where 
    F: FnMut<R>(&T) -> bool,
    R: ?const ?async !panic !unwind
{}

struct<R: ?const ?async !panic !unwind> File<R> {
    async waker: Waker,
    !async meta: Metadata,
}

impl<R: ?const ?async !panic !unwind> Read<R> for File<R> {
    fn<R> read(&mut self, buf: &mut [u8]) -> io::Result<usize> { .. }
}

Also, there is an inconsistency in the keyword position. For traits, impls, & structs the generics come after the keyword but for functions, they come before. I think the above syntax solves that problem as well.
The main issue I see with this approach is that since it looks like a generic, someone might try to add normal trait bounds to the generic. Also, the compiler should fill in the generic without the user having to provide it.
Eg:

fn main() {
    let file = File::new();
    let out = read_to_string(file).unwrap();
}

[leslie255]

Would it be possible to leave out the fn: part like this?

I don't think this would create any ambiguity for the parser, since type generics are followed by : and keyword generics are followed by if, and async and const are already keywords.

fn foo_finder<It, Cl, I>(iter: It, closure: It) -> Option<I>
where
    It: Iterator<Item = I>,
    Cl: FnMut(&I) -> bool,
    async if It: async + Cl: async,
    const if Cl: const,
    !panics if It: !panics + F2: !panics
{ /* ... */ }

[obsgolem]

keyword generics are followed by if

This might not necessarily be true; an unconditional effect could be expressed using the postfix notation. It might still be unambiguous though.

[satvikpendem]

Yeah something that is const or async doesn't necessarily have to have a conditional attached to it, as in the examples in my comment above, they can still be maybe const or not async, for example, with no conditions on when they would be.

[leslie255]

This might not necessarily be true; an unconditional effect could be expressed using the postfix notation. It might still be unambiguous though.

For empty type generic constraints rustc requires you to add a :, so it is only consistent to require empty keyword generic constraints to also have an if:

fn f<T>()
where T:,
{ // rustc requires you to add a `:` after `where T`
}
fn g()
where async if,
{ // should also require an `if` after `where async`
}

[satvikpendem]

if would be consistent but it feels weird semantically. Async if...what? Nothing? Maybe we should just have a colon after async and const as well too.