[Pre-RFC]: Unnamed struct types

[Veedrac]

@nrc I’d go for the simplest solutions to your nits:

canonical ordering

Alphabetical. (I originally went with arbitrary, but on further thought it’s not like it poses a back-compat issue.)

repr attributes

Not initially supported.

parsing ambiguities

Use a comma, exactly like with tuples. (x) and {x} are already basically synonymous, so it makes sense to “escape” them the same way as (x,) and {x: y,}.

the .. syntax

Seems like that’s best left to a different RFC.

[nrc]

I don’t think any of those are as simple as that. There are a bunch of trade-offs for all of these things. At the least, some investigation needs doing.

[iopq]

I meant by the API author, not by the compiler. I’ve updated the post.

[Veedrac]

What difficulties are you envisioning?

[Manishearth]

It is not suggesting that {foo: u8,} and struct Foo { foo: u8 } are different and non-interchangeable types. It is trying to instead meld the former into the latter type.

When it says “this might be changed to”, it doesn’t mean that there will be a magical coercion; it means that the API author will change the API to use anonymous types.

[nrc]

Briefly:

canonical ordering

We almost certainly want to allow the compiler to choose optimal orderings, but at the same time they must be consistent, and for C interop we will want to allow the ordering to be specified.

repr attributes

Initially supported or not, we need to ensure that the design can accommodate them somehow and that they can be added backwards compatibly (which is a big ask since if they affect the ordering this must be an implicit part of the type).

parsing ambiguities

The parser has all kinds of special rules around structs, blocks, and braces. Treatment of : is not exactly straightforward either. I’d want to be sure that we can in fact add anon structs without breaking these subtle special cases. Saying “just use a comma” is insufficient.

the … syntax

Again, even if it is not in a first implementation, we need to think about how it will be incorporated in the future and that there is room in the design for it, plus backwards compatibility.

Here and in the case of repr attributes, we would want to know now whether we could support these aspects in order to assess the desirability of the feature as a whole.

[Veedrac]

By “canonical ordering” I assumed you were talking about things like Debug and printing types.

The internal ordering is of course unspecified, just like every other non-repr struct in Rust. It doesn’t make sense to let people specify the order because that creates a distinction between {x: i32, y: i32} and {y: i32, x: i32}, but those types are identical. Any way of enforcing order is better done through writing a nominal type.

we need to ensure that the design can accommodate them somehow

Why? Nobody has needed them so far. I believe tuples aren’t FFI safe either - at least the Rustonomicon says

DSTs, tuples, and tagged unions are not a concept in C and as such are never FFI safe.

Anonymous structs as proposed are also “not a concept in C”, so they would equally not be FFI-safe.

Saying “just use a comma” is insufficient.

Fair enough on this one - the grammar needs to be more than just unambiguous.

we need to think about how it will be incorporated in the future

I don’t see how .. can cause a back-compat issue.

[cristicbz]

A suggestion which sidesteps most of @nrc’s concerns (except parsing) would be to treat {a: i8, b: u32} as a ‘struct literal’ similar to ‘integer literals’ whose specific type gets resolved by inference. So you’d have

struct Options {
   foo: String,
   bar: f32 = 2.5,   // default args
   baz: u32 = 10,
}

fn do_something(options: Options) { /* ... */ }

do_something({foo: "oh no!".to_owned()});

let options = {foo: "hello".to_owned(), baz: 24};
/*...*/
do_something(options);  // type of `options` gets resolved to `Options` and
                        // missing arguments filled in.

Layout, repr etc still get decided on the Options struct, without any additional syntax, but you still gain the ergonomics (in particular around not having to import additional types). @iopq suggested types can be added backwards compatibly (with unspecified layout/repr—similar to tuples) and can serve as the i32 fallback equivalent to a struct literal.

[ubsan]

This feels very much like std::initializer_list (which isn’t a bad thing).

[cristicbz]

I missed that connection, but it’s a good point, especially in the fallback to unnamed struct type case, since initializer_list is nameable after all.

It also feels a lot like initializer_list if used as a return value:

struct Foo {
    x: Vec<u32>,
    y: u32,
}

impl Foo {
    fn new() -> Self {
        { x: Vec::with_capacity(16), y: 20 }
    }
}  

I think that’s pretty rad.

[eternaleye]

One place I’d like to note that this would be quite useful is in associated types, and another is in defining purely internal field types with less boilerplate. To abuse the classic example of shapes:

struct RectangleClassic {
    width: u64,
    height u64,
    red: u8,
    green: u8,
    blue: u8,
}

struct RectangleTidy {
    dimensions: {
        width: u64,
        height: u64,
    },
    color: {
        red: u8,
        green: u8,
        blue: u8,
    },
}

This occupies a nice point in between writing things out completely flat (RectangleClassic), using classic tuples, and factoring things out into entire types of their own. Unlike RectangleClassic, members with correlated behaviors are kept together. Unlike tuples (but like RectangleClassic), each field has a meaningful name. Unlike creating new nominal types, boilerplate is still kept to a minimum.

in addition, I feel these would provide a valuable midpoint along any eventual refactor from RectangleClassic to distinct types - while tuples would force a garden-path divergence where the developer removes names and then re-adds them, and custom types require #[derive] boilerplate for Copy, Clone, Debug, etc, these types (presuming that, like tuples, those traits are sensibly defaulted) have none of those drawbacks.

[Ericson2314]

So IIRC C anonymous structs in anonymous unions (as opposed to other anonymous thing in non-standard C), would be served by this. So a #[repr(..)] is something we’d want. I do like the literal idea, in that the repr should only be on a type so one would do ({ foo: x, bar: y }: #[repr(C)] { y: /* comes first*/ int32, x: ) or something to disambiguate.

[scottmcm]

I quite like @cristicbz’s “struct literals” idea here.

There’s a nice symmetry here:

let i = 0i32;
let p = Point { x: 0, y: 0 };
// or
let i : i32 = 0;
let p : Point = { x: 0, y: 0 };

Inference would still need to unambiguously find the type, all the #[derive] stuff goes in the usual place, but where something else made it clear, you don’t have to say what it is explicitly.

That gets the usage of the API to be exactly the same as proposed in the OP’s piston example. And I don’t think that it’s unreasonable for the API designer to make named structs for such things. Certainly I could imagine things like Position::Origin to pass instead of { x: 0.0, y: 0.0 }.

Default arguments would end up looking like Foo({ a: 32, .. FooArgs::default() }), I guess? That’s not all that bad, actually, for a purely library solution…

(Hmm, I wonder whether .. syntax would be sufficient to infer a type for a ‘struct literal’?)

[elahn]

Currently you cannot do #[repr©] on anonymous tuples, so similarly you wouldn’t be able to #[repr©] on anonymous records either, which means I can’t actually use them in winapi.

This could potentially be solved with module-level #![repr(C)], so all structs and tuples, named and unnamed are #[repr(C)]. The ‘struct literal’ at the call site is inferred to be the unnamed type defined in the FFI module.

[iopq]

it’s worse, it’s

fn area(Args { width, height }: Args) -> u32 {
    width * height
}

note you have to write Args twice

[Storyyeller]

I like the idea of having an equivalent of anonymous tuples with named fields. From a language consistency standpoint it makes sense. There is an unnamed equivalent of tuple structs, so why is there no unnamed equivalent of regular structs? Plus, sometimes you want something that behaves like a tuple, but with more readable names for the fields.

In order to be consistent, it should be treated similarly to how tuples are treated today. That means no repr, no C FFI, no implicit type conversions, etc.

On the other hand, I don’t think this will be useful for APIs as suggested by the author. When I see code like this, I would never dream of writing it, because it is so unnecessarily verbose, and I hope that API authors would not inflict this on their users.

rectangle({red: 1.0, blue: 0.0, green: 1.0, alpha: 1.0},
     {position: {x: 0.0, y: 0.0}, size: {width: 100.0, height: 100.0}},
     c.transform, g);

As for canonical ordering, that seems like an easy problem to solve. For Debug, just print them in lexicographic order (either by utf8 bytes or by code point, doesn’t really matter which you choose as long as it is easily understandable), and for the memory layout, leave it up to the whims of the compiler.

[bbatha]

If the trait fields RFC gets accepted, impls for anonymous structs feel like a natural extension, just like impls for tuples, e.g.

impl<A, B> Foo for (A, B) { /*...*/ }

// maybe use (a :A, b :B) if the grammar doesn't play nicely.
impl<A, B> Bar for { a: A, b: B } {
     a = a;
     b = b;
}

If the generic tuples RFC gets accepted maybe it should apply to structs too so that many procedural macro style impl can be written generically.

impl<A: Clone, ...Tail: Clone> for (A, ...Tail) {
   /* ... */
}

You’d probably still need macros for things that need field names, e.g. Serialize and it might be too magical anyway.

[kardeiz]

Unnamed structs would also be pretty great for deserializing one-off structures with serde. Sometimes when deserializing a JSON response, you will want to ensure that the response fits a certain structure, but will only care about field names (rather than struct names), for example when you are just extracting a couple Strings from a deeply nested object.

This would be nice for serializing as well, but (for JSON at least) the newish json macro in serde_json already provides a nice interface for the producer side of things (albeit with presumably some overhead).

[Centril]

I’ve proposed this formally:

RFC: Structural Records

[system]

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