[Pre-RFC]: Unnamed struct types

[ticki]

Omitting the type is one thing (although I do oppose that as well), but literally allowing for closure-like struct types is a quite big change with little benefit.

Despite, there is a parsing ambiguity, there is a parsing rule, '{' EXPR '}', which this clearly breaks given that EXPR := EXPR ':' TY | ....

Secondly, there are a lot of other problems here. One of them is encouraging long, untyped argument lists, which is generally considered an anti-pattern.

Now, introducing such an feature would mean splitting the whole ecosystem into two, incompatible forms of passing arguments.

The {...,} syntax is rather strange as well.

I could go on, but my general opinion is that this is a very bad idea with little benefit.

[ticki]

Also, tuples aren’t duck types. Semantically, they are equivalent to structs.

[dan_t]

[quote=“ticki, post:38, topic:3872, full:true”]Despite, there is a parsing ambiguity, there is a parsing rule, ‘{’ EXPR ‘}’, which this clearly breaks given that EXPR := EXPR ‘:’ TY | …[/QUOTE]

Anonymous structs with one field certainly won’t be used that much, but you can still require them to be written with a trailing comma { x: i32, }, which should solve the parsing problem.

[quote=“ticki, post:38, topic:3872, full:true”]Secondly, there are a lot of other problems here. One of them is encouraging long, untyped argument lists, which is generally considered an anti-pattern.[/QUOTE]

You can say this for pretty much every feature, that there are good and bad uses of and I can see how anonymous structs can help solving the named/default parameter case.

I wouldn’t consider it to be the nicest syntactic way for named/default parameters, but all the other ways have their own issues, which might even have a bigger impact on the whole language, and any solution for named/default parameters will most likely be opt-in, so there will be a difference between functions/methods with and without named/default parameters.

[iopq]

The {…,} syntax is rather strange as well.

It’s to avoid syntactic ambiguity in the case of a single member struct. The same syntax is used for tuples like (i8,)

One of them is encouraging long, untyped argument lists, which is generally considered an anti-pattern.

Currently those things are implemented by tuples (f32, f32, f32, f32) or arrays [f32, 4] which is even less clear. What does that argument even mean? If I give you an API that has an argument of type {red: f32, green: f32, blue: f32, alpha: f32} I would consider this to be very clear intent. I don’t consider Rgba {red: f32, green: f32, blue: f32, alpha: f32} in any way more clear.

Furthermore, I think it’s much easier to pass around {red: f32, green: f32, blue: f32, alpha: f32} - different crates can use this exact format by agreement. If you have Rgba {red: f32, green: f32, blue: f32, alpha: f32} for this purpose - then where is it declared? Which crate does everyone else import this type from?

[bbatha]

it also makes the code more verbose when using these arguments (args.my_named_arg).

You can use irrefutable pattern matches in fn signatures, including on named structs in rust today. https://is.gd/TeJQGx I don’t see why their anonymity would make a difference.

[KiChjang]

There’s no coercion going on, only new types. Anonymous structs are not coerced to tuples.

Just how (u8, ) and struct Foo(u8) and struct Foo{foo: u8} are different types, {foo: u8,} is also a different type and not interchangeable with {bar: u8,}, or any of the other types I just named.

I don’t think this is what this pre-RFC is suggesting. On the motivation section, there’s this example:

window.addNewControl(“Title”, 20, 50, 100, 50, true);

this might be changed to

window.addNewControl({title: “Title”, x: 20, y: 50, width: 100, height: 50, drawingNow: true});

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.

[cuviper]

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.

Whether @iopq intended it or not, I think the clear consensus here is that they should be distinct, just as tuples and tuple-structs are distinct.

[KiChjang]

Whether @iopq intended it or not, I think the clear consensus here is that they should be distinct, just as tuples and tuple-structs are distinct.

My sentiments are shared with @withoutboats, if simply a tuple with named fields are being introduced, then I’m fine with it. What I am strongly against is treating this new type as a substitute for structs in parameters (which I think is the true purpose of this pre-RFC).

[retep998]

What I am strongly against is treating this new type as a substitute for structs in parameters (which I think is the true purpose of this pre-RFC).

I’m pretty sure that is not the purpose of this pre-RFC.

Anyway, I have become aware of a realization that would prevent me from using this in winapi. Currently you cannot do #[repr(C)] on anonymous tuples, so similarly you wouldn’t be able to #[repr(C)] on anonymous records either, which means I can’t actually use them in winapi. Looks like I’ll be stuck with naming all my types

I still like this pre-RFC though.

[nrc]

I’m in favour of this feature and think it is a step in the right direction towards a named field solution. I do think there are some nitty details to address (canonical ordering, repr attributes, parsing ambiguities, the .. syntax, etc.), mostly suggested in this thread.

I wouldn’t worry too much about defaults for now, I would like to see (separately) an RFC for default struct fields (I don’t think Default is a complete solution even for named structs).

[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.