Is the anonymous struct (unnamed struct) still in progress?

language design
1

Hello everyone,

Does anyone know the latest progress on anonymous structs (or unnamed structs)? I've looked through many posts, but they are all from a long time ago. I wonder if the development of the anonymous struct (or unnamed struct) feature is still ongoing?

2 Likes
2

I am not aware of any proposal that thorough enough to warrant an experimental implementation, let alone something RFC-accepted.

3

There are several different features here that sometimes get conflated under various similar names.

One is the idea of an anonymous struct type, similar to a tuple with named fields: { field: value }. To the best of my recollection this never really got off the drawing board, has a lot of design questions that would need answering (e.g. how is it typechecked, how does it interact with non-anonymous struct types), and seems unlikely to make progress. It's an interesting idea, but it's not clear if we want it or if the complexity buys us enough value to be worth it.

(Relatedly, there's the idea of traits with fields; that had some serious design discussions, but also didn't get off the ground.)

One is the idea of being able to pass a struct to a function without having to name it. This more commonly uses the name "elision". For instance, func(_ { field: value }). That's been discussed many, many times. I think Inferred types `_::Enum` by JoshBashed · Pull Request #3444 · rust-lang/rfcs · GitHub is the latest attempt. It doesn't seem excessively complicated. It's not clear if we have consensus to do it, but it wouldn't be hard to do if we have that consensus.

One is the idea of unnamed struct/union fields, used as a grouping mechanism for structure layout, to handle things like the common C "struct of union of structs" pattern:

struct S {
    variant: u32,
    _: union {
        i: i32,
        f: f32,
        _: struct {
            x: i16,
            y: i16,
        }
    },
}

This has an accepted RFC (RFC 2102), but hasn't been implemented, and there have been some design concerns raised. It needs someone to pick up and revive this work, do an initial implementation, raise any design concerns that that implementation raises, and drive it towards stabilization. (I'd be very happy to help with this, but don't have the bandwidth to do all of that right now.)

5 Likes
4

See the tracking issue for more on the current state of that. In particular, there has been an implementation attempt, but it got removed since it had a bunch of problems:

This requires some implementation design work to figure out how to fit it into the compiler without changing everything about how we represent types.

That implementation uncovered some lang-level issues as well that maybe should be answered before attempting another implementation.