# \[Pre-RFC\]: Unnamed struct types

**URL:** <https://internals.rust-lang.org/t/pre-rfc-unnamed-struct-types/3872>\
**Category:** language design\
**Created:** [August 17, 2016, 11:36pm UTC](https://internals.rust-lang.org/t/pre-rfc-unnamed-struct-types/3872 "2016-08-17T23:36:03Z")\
**Posts on this page:** 1\
**Showing post:** 55

<div class="post-metadata">

**Author:** ![cristicbz](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cristicbz/32/935_2.png) [@cristicbz](https://internals.rust-lang.org/u/cristicbz)\
**Post date:** [October 11, 2016, 10:28am UTC](https://internals.rust-lang.org/t/pre-rfc-unnamed-struct-types/3872/55 "2016-10-11T10:28:12Z")

</div>

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

```rust
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.

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-unnamed-struct-types/3872)._