Stream: t-lang

Topic: Removing assignment as a way to get () values

Lokathor (Apr 20 2020 at 23:38, on Zulip):

I some wrote code as recently as today that involved doing Ok(self.val = new_val) as the last line of a function to trim away having Ok(()) as its own line, examples:

So please don't invalidate that.

Josh Triplett (Apr 21 2020 at 04:03, on Zulip):

That seems rather inscrutable.

Josh Triplett (Apr 21 2020 at 04:05, on Zulip):

Also, you should be getting a warning about "otherwise" being unused.

Lokathor (Apr 21 2020 at 04:25, on Zulip):

Yes, otherwise is unused at the moment. If this becomes the final form of the function and i don't end up braking apart the error conditions more then i'll put an underscore on the name. Until then about half the project just has allow(unused) on it.

Lokathor (Apr 21 2020 at 04:31, on Zulip):

Also, the code seems fairly clear to me. Though I am the author so naturally I'd end up being more comfortable with it.

I'd say that in general I like code that's visually compact, so I end up making things a little different from normal.

For example, in other parts of the same project I write try_from instances like this:

impl TryFrom<u8> for PngColorType {
  type Error = PngError;
  fn try_from(color: u8) -> Result<Self, PngError> {
    Ok(match color {
      0 => PngColorType::Greyscale,
      2 => PngColorType::Truecolor,
      3 => PngColorType::Indexed,
      4 => PngColorType::GreyscaleAlpha,
      6 => PngColorType::TruecolorAlpha,
      _ => return Err(PngError::IllegalColorType { color }),

and it all feels quite natural to me.

kennytm (Apr 21 2020 at 05:06, on Zulip):

if we follow RFC 2443 you should still be able to use Ok((self.val = new_val)) or Ok({ self.val = new_val }). but Ok(self.val = new_val) is already warned by clippy::unit_arg.

Lokathor (Apr 21 2020 at 08:29, on Zulip):

I'd use clippy more but rust-analyzer doesn't really seem to support it, and i generally want RA support more than clippy support

nikomatsakis (Apr 21 2020 at 16:51, on Zulip):

Lokathor said:

So please don't invalidate that.

I feel like that's arguably a feature request for Ok-wrapping :)

Lokathor (Apr 21 2020 at 20:01, on Zulip):

Yes, you could read it like that. If there was a better way to have Ok-wrapping happen then I also wouldn't mind a change.

Charles Lew (Apr 22 2020 at 11:54, on Zulip):

I feel there's some correspondence between "keyword arguments" and "field initializers", it would be nice if they can use same symbols.

Charles Lew (Apr 22 2020 at 11:56, on Zulip):

Aside from "=", maybe ":=" is a nice choice too :)

nikomatsakis (Apr 22 2020 at 20:09, on Zulip):

I recall that Nick Cameron felt that Foo { x = y } would have been a better choice of syntax.

nikomatsakis (Apr 22 2020 at 20:09, on Zulip):

Bit late for that.

Josh Triplett (Apr 22 2020 at 20:09, on Zulip):

It is, though I do wonder if it might be possible to introduce one day. :)

varkor (Apr 22 2020 at 20:10, on Zulip):

So, so much better :)

varkor (Apr 22 2020 at 20:10, on Zulip):

: for field assignments conflicts with several other syntax proposals IIRC.

varkor (Apr 22 2020 at 20:10, on Zulip):


scottmcm (Apr 22 2020 at 22:23, on Zulip):

@Charles Lew We currently (conceptually) have "tuple struct literals" sharing syntax with "positional-argument function calls"; I've been pondering whether we could just have "named struct literal" syntax also be used for "named-argument function calls"...

scottmcm (Apr 22 2020 at 22:26, on Zulip):

@Josh Triplett We _could_ introduce it whenever we want, right? I don't think ident { ident = in expression position is a conflict, since the preceding ident distinguishes it from a block with an assignment. (Weighing the churn being a completely different conversation, of course.)

Josh Triplett (Apr 22 2020 at 22:42, on Zulip):

Right. It could be a stylistic choice, if we wanted it to be and felt it wouldn't be confusing.

varkor (Apr 22 2020 at 22:43, on Zulip):

There's very little benefit in having it be a stylistic choice: the primary reason to switch is to eliminate the ambiguity with things like type ascription.

varkor (Apr 22 2020 at 22:44, on Zulip):

Phasing it out slowly would not be ideal; you would probably want to switch on an edition change and rustfix it.

varkor (Apr 22 2020 at 22:45, on Zulip):

(It could be an interesting experiment to take a large codebase, and see what it looked like with = instead of :.)

simulacrum (Apr 23 2020 at 00:40, on Zulip):

Seems like it is probably a fairly straightforward change to make in the parser, so at least in theory we could land that and then rustfix rust-lang/rust or so.

Last update: Jun 05 2020 at 23:10UTC