# \[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:** 60

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [November 27, 2016, 6:16am UTC](https://internals.rust-lang.org/t/pre-rfc-unnamed-struct-types/3872/60 "2016-11-27T06:16:16Z")

</div>

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

There’s a nice symmetry here:

```rust
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’?)

---

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