Hacker News Reader

>I've lost count of how many times in Rust I had an "o: Option<(A, B)>" and a "f: fn(A, B) -> C" and couldn't call "o.map(f)"

Non-serious solution:

    #![feature(fn_traits, unboxed_closures)]

    pub fn foo<Args, C>(o: Option<Args>, f: impl FnOnce<Args, Output = C>) -> Option<C> {
        o.map(|v| f.call_once(v))
    }

https://doc.rust-lang.org/stable/std/ops/trait.FnOnce.html

"Non-serious" because it won't be stable any time soon, and it's not as concise as `o.map(f)` anyway.

More seriously, I don't think `o.map(f)` will ever happen, because it'll be backward-incompatible in the case of `o: Option<(T,)>` and `f: <U>impl FnOnce(U)` - `U` used to be `(T,)` and now would be `T`. Something like `o.map(spread(f))` might work if vararg generics are added to allow a generic `spread` that works for any tuple and matching-arity FnOnce.

There's

    o.expect("Error")?.map(f)

if you just need to convert a Option to a value in-line and None is an error.

Also the rather bulky

   o.ok_or_else(|| anyhow("Error"))?.map(f)

I've been writing too many of those forms lately, decoding a tree data structure of known form which might be wrong, but usually isn't.

I assume you meant `.ok_or`, not `.expect`. Either way, I'm not really how this or your `.ok_or_else` comment is relevant to this sub-thread. `.map` is not a method on tuples.

[EDIT: comment applicable only to an older version of the parent comment]

This "foo" still suffers from the same problem as "Option::map" does: it is hard-coded for functions of fixed arity (2 in this case, 1 in Option::map's case).

Needing to write this function doesn't shorten the code. The SML-inspired solution allows one to write an "Option::map" which accepts functions of all possible arities (since they are all 1).

But yes, if there are a lot of places where I want to call "Option::map" for an "f" which takes 2 arguments, that could work. Although, personally, I think I'd still opt for an explicit lambda, in order to communicate intent more directly (avoid one level of indirection).

>This "foo" still suffers from the same problem as "Option::map" does: it is hard-coded for functions of fixed arity (2 in this case, 1 in Option::map's case).

Hence the last paragraph in my comment.

Sorry. I didn't see it before. You're right.

Actually, I'm sorry too. I just realized I had a brainfart while writing that example and forgot to make the point I wanted to make. I've fixed it now. (It was supposed to work with any-arity tuples as well.)

> the function's argument is a tuple (this is the more common way, not only in SML, but also how it's done most commonly in maths);

The Ceylon programming language worked that way[1] and it was really cool to be able just what you wanted: `o.map(f)`.

It's a shame that other languages didn't seem to pick up this idea... I've no idea if this could be made to work in Rust though (given Rust has no GC and it would go against its philosophy to allocate parameters like this on the heap just to create tuples - maybe the compiler could get rid of the actual tuples altogether?).

[1] https://ceylon-lang.org/blog/2012/12/21/tuples-and-functions...

Even though Ceylon uses tuple types to represent parameter lists, a function accepting multiple arguments (with the parameter list represented by a tuple: Callable<Void, [Integer, String]>) is still different from a function accepting a tuple of multiple fields (with the parameter list represented by a tuple of a tuple: Callable<Void, [[Integer, String]]>). You can’t just call one as if it were the other. Ceylon works the same way as Rust here, as far as I can tell.

BTW, for Rust beginners who might be concerned that o.map(f) is somehow a difficult problem, the solution in Rust is simple: o.map(|(a, b)| f(a, b)).

Swift had this feature until version 2.3 it was removed in 3.0 because it added a lot of complexity and seemingly confused users. I’d search for a link but I’m on mobile

Rust tuples are on the stack, to have them on the heap you need to explicitly use Box.

Funnily enough, internally this is how closures parameters are represented internally, as a single argument that is a tuple of all its parameters.

Perhaps you meant that variables which are closed over are in an anonymous struct or in a tuple. I am fuzzy about the details but as far as I know parameters are passed like as in other functions.

Rust represents closures in the following way:

    pub trait Fn<Args> {
        type Output;

        extern "rust-call" fn call(self, args: Args) -> Self::Output;
    }

where Args is a tuple of all the actual arguments.

You used to be able to cause an ICE on nightly if you used something other than the correct argument[1], but instead it now tells you that it should have been a tuple:

    error: functions with the "rust-call" ABI must take a single non-self argument that is a tuple
     --> src/main.rs:7:5
      |
    7 |     extern "rust-call" fn call_once(self, args: i32) -> Self::Output {}
      |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    error[E0059]: cannot use call notation; the first type parameter for the function trait is neither a tuple nor unit
      --> src/main.rs:12:5
       |
    12 |     x(42);
       |     ^^^^^

[1]: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Huh. That's really slick.

I stand corrected.

Having enum variants be structs has been proposed, and that could solve your issue if `mem::disciminant<Enum::Variant>` returned what you wanted.

> Having enum variants be structs has been proposed

That's great news.

> that could solve your issue if `mem::disciminant<Enum::Variant>` returned what you wanted.

I think you misunderstood, or I explained it poorly.

Given an:

  enum Enum {
      A(int),
      B,
  }

I would like mem::Discriminant<Enum> be the same type as if there was such a definition in code (illegal in Rust, because Rust doesn't have specializations):

  enum mem::Discriminant<Enum> {
      A,
      B,
  }

Ah, I did misunderstand. That’s an interesting idea.

> the "strum" crate, which has a macro to produce another (plain) enum, but having the discriminant type be named "std::mem::Discriminant<T>"

I don't understand, is this a copy/paste mistake?

You cut out the rest of the sentence, which is needed to make sense of it.

What I mean is, with the "strum" crate I can use a proc macro to automatically generate an "EnumDiscriminant" enum for an "Enum" enum, where "Enum" is defined as:

  enum Enum {
      A(u32),
      B,
  }

and "EnumDiscriminant" is defined as:

  enum EnumDiscriminant {
      A,
      B,
  }

However, the only thing linking those two is a naming convention. I would like to have a universal name for such discriminants.

The Rust standard library already has such a discriminant type for any enum - mem::Discriminant<T>, where T is the enum type. However, in order to get the discriminant of Enum::A(5) I need to write mem::discriminant(Enum::A(5)), which introduces noise (especially with bigger tuples or structs) - this 5 here is irrelevant. The mem::discriminant() function is useful for contexts where I have a variable of type Enum and want to get its discriminant, but when I just want to pick a particular discriminant, it's too noisy. I would like to be able to name the discriminant directly. I.e. I would like the standard library type Discriminant<T> be defined for each enum the same way EnumDiscriminant above is defined for Enum. So I could just write Discriminant::<Enum>::A.