Comment by satvikpendem | Hacker News Reader

Comment by satvikpendem | Hacker News Reader

For those of you following along with keyword generics in Rust, the current proposal is this [0]:

    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)
    }

which was rightfully disliked [1]. There have been some other proposals however, such as this one I wrote about [2]

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

for which someone made a more detailed issue [3]. It is similar to a `where` clause in that the `effect` clause comes afterwards and defines the effects that a function can have.

[0] https://blog.rust-lang.org/inside-rust/2023/02/23/keyword-ge...

[1] https://old.reddit.com/r/rust/comments/119y8ex/keyword_gener...

[2] https://github.com/rust-lang/keyword-generics-initiative/iss...

[3] https://github.com/rust-lang/keyword-generics-initiative/iss...

What you’re highlighting here is something we explicitly call out in the blog post as what we don’t want people to have to write. We agree the syntax is noisy and would be bad to work with. We instead would prefer it if people could write something like this instead, which would have the same semantics as `?const ?async fn`:

    effect fn read_to_string<R>(reader: &mut R) -> io::Result<String>
    where
        R: effect Read
    {
        let mut string = String::new();
        reader.read_to_string(&mut string).do;  // note the .do here
        string
    }

The exact syntax of the design is something we’re far less committed to than the semantics of it. But we didn’t do a good enough job at communicating that in our last post, so that’s on us.

Why would you want the function to run over all effects instead of explicitly outlining what effects you want the function to run on? It seems like the latter is more verbose but more explicit.

Not all effects, but a select set which are covered by the `effect` keyword. That set could change over edition bounds. The reason for that is because we don't just care about maximum expressivity, we also care about ensuring good readability. It would be really bad if every function, type, and argument had to repeat `?const ?try ?async ?panic ?send ?leak ?sized` and other effects over and over and over. Having a keyword to represent a set of effects which functions are expected to be generic over seems like the better option.

I do hope that in maybe 2027 or 2030 we can switch the stdlib over to const-by-default, so `const` would no longer has to be part of the effect set. But it's unlikely we'll ever want to implement "async-by-default" or "try-by-default". So there likely will always be a need to name a set of effects which functions can be generic over.

I think the issue about syntax is that the ?-mark soup doesn't look great, but many people likely won't mind something like the `where effect` proposal that I mentioned above. Still, I understand your point about having an effect keyword in general.

Yay, I’m glad that made sense!

And the way you'd do it with this library is

    // very complex and powerful API
    effing_mad::effects! {
        Read {
            fn read_to_string(bug: &mut String) -> Result<usize>;
        }
    }

    #[effectful(Read)]
    fn read_to_string() -> io::Result<String> {
        let mut string = String::new();
        (yield read_to_string(&mut string))?;
        Ok(string)
    }

and then to call it, you would do

    let handler = handler! {
        Read {
            read() => reader.read(),
        }
    };

    let action = handle_group(read_to_string(), handler);
    let result = run(action);

If Rust had algebraic effects, your example would be:

  fn foo<T,E>(closure: impl FnMut(&T) -> bool | E) -> Option<T> | E

All that's needed syntax-wise would be a way to attach one or more type parameters to a function type. (I used "|" here but it could be anything)

I really hope the ??? vomit isn't accepted.

You have to read the post related to this proposal (first link). It shows why it makes sense more than whatever is proposed in this thread.

I agree that it looks like trash, though.

No it doesn't, not in the form it is proposed.

Sometimes aesthetics matter though, and this is certainly a candidate

Reply on news.ycombinator.com