Subteam reports 2016-04-1

[aturon]

Lang

Full report

Due in part to missing team members, two RFCs that were already in FCP are staying in FCP for another week:

• FCP PR #1398: Allocators, take III
  • Left detailed comments here and summarized here.
• FCP PR #1513: RFC: Stabilize implementing panics as aborts

In addition, we reached final decisions on two long-standing FCP RFCs:

• FCP PR #1321: Unstable visibility RFC
  • Close.
• FCP PR #1346: Unsafe expressions
  • Close.

We also brought a couple of new RFCs into final comment period, leaving us with the following list for the week:

• FCP PR #1319: Amend RFC1228 with operator fixity and precedence
• FCP PR #1373: Remove some kinds of doc comments
  • Proposes deprecating #[doc=""], #![doc=""], /** */, and /*! */.
• FCP PR #1398: Allocators, take III
  • Proposes a comprehensive API for describing and using allocators, with the intent that types like Vec and HashMap can ultimately support custom allocators.
• FCP PR #1444: unions
  • Proposes a C-like union keyword in Rust, useful for FFI as well as a few pure-Rust scenarios (like manually-dropped data).
• FCP PR #1494: Amend RFC 550 with misc. follow set corrections
• FCP PR #1513: RFC: Stabilize implementing panics as aborts
  • This RFC adds various options to allow the “end crate” (e.g., the application) to specify that panics ought to be compiled as aborts, rather than initiating unwinding. This is useful for applications that would prefer to crash the process, since supporting unwinding causes more code generation and can inhibit some optimizations.
  • The end-user model we are aiming towards with this RFC is that panics mean "abort and let somebody else handle it" – in the case of unwinding, that "somebody else" may be another thread, but in the case of aborting, that "somebody else" is another process.

Libs

Full report

We discussed several RFCs that were previously in FCP:

• FCP PR #1398: Allocators, take III
  • Left detailed comments here and summarized here. Due to ongoing discussion and coordination with lang team, this is staying in FCP for another week.
• FCP PR #1529: rfc 1291: Add libutil to scope of libc crate on Linux
  • Merged, due to the relevant library being both ubiquitous and in particular provided in musl (a good indicator of standardization).
• FCP PR #1552: Add a contains method to VecDeque and LinkedList
  • Merged.

In addition, two new RFCs enter final comment period (FCP):

• FCP PR #1505: Add a generic Atomic type
• FCP PR #1543: Add more integer atomic types

Both of these RFCs address the desire for additional atomic types, but through different routes; we will accept at most one of them.

We also discussed the encode_utf8 situation; this was a case where an API was stabilized within libcore by accident, but not within libstd. We landed a breaking change to the API in both locations, and moved back to proper unstable status in libcore. We consider the latter to be a bug fix, but also did due diligence in terms of trying to gauge usage (and taking into account that using the API purely through libcore is pretty niche in the first place). This was a tough call, but we believe the right thing to do in this particular case.

We reached a decision on how to accommodate u64-sized division and multiplication for Duration without breakage; see https://github.com/rust-lang/rust/pull/32515.

Finally, we are landing our first trial use of specialization within std: speeding up the to_string method on string slices!

[leonardo]

Regarding unions:

A declaration fn union() {} will not produce such an error.

But I think such usage can be warned against, with a deprecation warning that could be kept in place for few years, and then “union” could become a true keyword…

[jethrogb]

First we’d need to come up with a new name for https://doc.rust-lang.org/stable/std/collections/struct.HashSet.html#method.union

[leonardo]

First we’d need to come up with a new name for https://doc.rust-lang.org/stable/std/collections/struct.HashSet.html#method.union

Ah, right. In a Set data structure written in D but with an API as similar as possible to the Python Set, I think I used the function “unite”

But even better is perhaps to use the keyword “unsafe_union” instead of just “union”. This avoids the problem with all Set APIs, and avoids most of other naming collisions. The longer name is not as nice as “union”, but I am not going to write unions all the time in Rust, so I think a bit longer keyword is not terrible. And it helps avoid the complexities caused by contextual (key)words.

There are situations in Rust where I like code succinctness, but saving chars in the name of unions is not one of those cases, for me.

[josh]

But even better is perhaps to use the keyword “unsafe_union” instead of just “union”. This avoids the problem with all Set APIs, and avoids most of other naming collisions.

In the long and storied history of the RFC, one iteration did use the keyword untagged_union.

The discussion around that brought up several points. It’s entirely possible for any new keyword to break existing code, even if it doesn’t break the standard library; someone could have a fn untagged_union() in their own code. Given that, it seems preferable to use the more ergonomic syntax. Quite a few people said they’d prefer union if the grammar could support it, and @nikomatsakis demonstrated that the grammar could support it.

[leonardo]

someone could have a fn untagged_union() in their own code. Given that, it seems preferable to use the more ergonomic syntax.

But different words have different probabilities of being used, so it’s not a binary decision. Like Rust, the D language doesn’t add keywords often, but in such situation I think they deprecate the “untagged_union” now and keep it deprecated for some months; later they make its usage a syntax error, and one or two compiler releases later they introduce the untagged_union{} new feature.

Quite a few people said they’d prefer union if the grammar could support it, and @nikomatsakis demonstrated that the grammar could support it.

But isn’t that making the compiler more complex or its design less clean? Rust is a quite new language, isn’t it a bit early to add hacks to it?

What’s the usefulness of having a Rust union where the layout of the fields is not repr©? (I have not found this explained in the RFC).

[vi0]

Why not #[repr(C,union)] with usual struct? The voting has also shown 49%-preference for the repr variant…

[josh]

But isn’t that making the compiler more complex or its design less clean?

I don’t think it makes the design any less clean. And @nikomatsakis’s work shows that it can be done without significant complexity increase.

What’s the usefulness of having a Rust union where the layout of the fields is not repr©? (I have not found this explained in the RFC).

Several uses:

• Creating your own space-efficient data structures, smaller than an enum, by relying on value range information that you can’t express in a type. For instance, tagged pointer/integer types.
• Implementing ManuallyDrop.

Why not #[repr(C,union)] with usual struct? The voting has also shown 49%-preference for the repr variant…

The poll in the thread pre-dated several other solutions and didn’t include them in the poll, including untagged_union, union!, and union. The only thing the poll shows is that people would prefer #[repr(union)] struct over unsafe enum.

[aturon]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.