Stream: wg-traits

Topic: Minimal Specialization


Taylor Cramer (Mar 20 2019 at 21:10, on Zulip):

Hey folks-- I've brought up the possibility several times of trying to stabilize a minimal version of specialization which only allowed specializing concrete types with no lifetimes, which I believe avoids all of the interesting soundness questions. It seems like there was some disagreement over whether or not this would be useful. I know I've personally wanted/needed specialization many times, and a minimal version like this would unblock many of my use-cases (e.g. making a performance-critical Vec<u8> trait impl fast as compared to a complex Vec<T: SomeTrait> impl, adding a base-case impl for a specific type where all other implementations delegate to that type, allowing casing on sealed traits over a small number of concrete types, etc.). @Joshua Liebow-Feeser and I would be interested in working on a proposal for something along these lines, but with the new working-group setup I'd like to make sure we're following the proper order of things WRT gathering working-group consensus and prioritization.

Are there others who would be interested in participating in this effort? Does this seem like something you'd be interested in prioritizing? (relative to other roadmap language features)

Taylor Cramer (Mar 20 2019 at 21:10, on Zulip):

(this post really belongs in t-lang/wg-traits, but sadly that does not exist)

Taylor Cramer (Mar 20 2019 at 21:11, on Zulip):

(cc @Aaron Turon and @centril who I believe have had thoughts about this in the past)

centril (Mar 20 2019 at 21:19, on Zulip):

I'd like an informal specification of what exactly is to be stabilized. Bugs that exist wrt. those need to be closed and the checkboxes on the tracking issue need to be addressed in some way. The more expressive specialization needs to be cordoned off into a new feature gate or the limited subset needs to be cordoned off into a new one (like with min_const_fn). Moreover, I think that surface syntax changes are needed, e.g. with where specialize(T: Foo), and there's no way around an RFC on that.

Taylor Cramer (Mar 20 2019 at 21:19, on Zulip):

@centril oh, to be clear, I would definitely expect that this would require an RFC

centril (Mar 20 2019 at 21:20, on Zulip):

I think it goes without saying that an elaborate stabilization report is necessary once we get to that stage with lots and lots of tests

Taylor Cramer (Mar 20 2019 at 21:20, on Zulip):

with a clearly specified set of supported cases, documented examples ensuring forwards-compatibility, as well as syntax resolutions

Taylor Cramer (Mar 20 2019 at 21:20, on Zulip):

yup

centril (Mar 20 2019 at 21:21, on Zulip):

Provided that all that happens and that the minimal subset is sufficiently useful, I don't see why not

centril (Mar 20 2019 at 21:21, on Zulip):

Tho I do think we shouldn't split our focus too much

Taylor Cramer (Mar 20 2019 at 21:21, on Zulip):

Yes, that would be the counterargument.

centril (Mar 20 2019 at 21:21, on Zulip):

and we should consider how much specialization sets us back wrt. chalkification

centril (Mar 20 2019 at 21:22, on Zulip):

I think @nikomatsakis @scalexm may have thoughts :slight_smile:

Taylor Cramer (Mar 20 2019 at 21:22, on Zulip):

Can you say more about why you'd imagine it would do so? maybe you're just asking us to consider and explicitly specify whether or not it has any effects

centril (Mar 20 2019 at 21:23, on Zulip):

@Taylor Cramer yes mostly the latter, but presumably we want to make -Zchalk the default one day and so I think that implies that specialization would need to be supported in chalk.

centril (Mar 20 2019 at 21:23, on Zulip):

The "support specialization in chalk" is what could take time

centril (Mar 20 2019 at 21:24, on Zulip):

But I defer the answer to that to Niko et. al. ^^

centril (Mar 20 2019 at 21:35, on Zulip):

One thing that would be nice is to disable #![feature(specialization)] and survey how many errors you get in the compiler & standard library

centril (Mar 20 2019 at 21:35, on Zulip):

and then categorize by "would be supported" and "would not"

nikomatsakis (Mar 22 2019 at 15:44, on Zulip):

Here are a few thoughts in no particular order:

Joshua Liebow-Feeser (Mar 26 2019 at 21:16, on Zulip):

I can speak to use cases, at least within Fuchsia.

In our Rust networking stack, we have two core traits that we use specialization on - Ip and IpAddress. Ip is implemented by Ipv4 and Ipv6 (ZST marker types) while IpAddress is implemented by Ipv4Addr and Ipv6Addr (actual IP addresses). We use specialization to add type-specific behavior to various generic functions.
- We have a proc macro for most use cases: https://fuchsia.googlesource.com/fuchsia/+/master/garnet/bin/recovery_netstack/core/specialize-ip-macro/. The Ip and IpAddress traits have no type arguments, and the concrete types which implement them also have no type arguments, so this is, IIUC, the simplest form of specialization.
- We have a number of custom extension traits which do have type arguments such as IpExt: https://fuchsia.googlesource.com/fuchsia/+/master/garnet/bin/recovery_netstack/core/src/ip/types.rs#903

IpExt is implemented like so:

    pub(crate) trait IpExt<B: ByteSlice>: Ip {
        type Packet: IpPacket<B, Self, Builder = Self::PacketBuilder>;
        type PacketBuilder: IpPacketBuilder<Self>;
    }
    impl<B: ByteSlice, I: Ip> IpExt<B> for I {
        default type Packet = !;
        default type PacketBuilder = !;
    }
    impl<B: ByteSlice> IpExt<B> for Ipv4 { ... }
    impl<B: ByteSlice> IpExt<B> for Ipv6 { ... }
Last update: Nov 12 2019 at 15:40UTC