Pre-RFC: Partial Borrow Syntax Sugar

[RustyYato]

The syntax for anonymous structs is ambiguous and inconsistent, I would require the struct keyword before the { ... }.

This seems similar to views, so similar in fact that the only difference is that these views are anonymous. So I don't this as a Partial Borrow Syntax Pre-RFC, more as a Anonymous Structs Pre-RFC. This has been seen before. I don't see the value in this as it is trivial to come up with a name for a view struct. Also, if you need to use it in multiple places, you will have to name it anyways.

Secondly, are these field names leaked if the fields are private, but the function is public?

[Pre-RFC]: Unnamed struct types

###Summary Rust already has these kinds of structs: struct Rgb (i8, i8, i8) the unnamed analog is (25i8, 25i8, 80i8) I am proposing that this is extended to make this struct Rgb { red: i8, green: i8, blue: i8 } have this unnamed analog { red: 25i8, green: 25i8, blue: 80i8 } in other words, tuples : tuple structs :: unnamed structs : structs ###Motivation Since tuples exist, they give a way to have duck-typed unnamed types. Tuples are defined by argument order. Structs are not. This is p…

Pre-RFC: anonymous struct and union types

From a quick glance, it seems that this proposal includes anonymous structs/unions only within struct/union definitions, but not as types in general. Is there a deep reason for that? All things being equal, it seems nicer to expand the type grammar, such that this isn’t a special case within type definitions but instead just another kind of type. A closely-related pre-RFC seems to be doing just that. (I haven’t thought deeply about the implications of any of this, but just wanted to note the ge…

Idea: reducing boilerplate in APIs that use ADTs

I like. _ in type context already means “please infer this”, so using it for struct literals makes sense. FRU is a documentation example for Default, and I can’t imagine any other no-parameter thing that would make sense. Plus the symmetry with pattern syntax is nice. (I also think that it’s cool that pseudo-code already tends to look like { a: 4, .. }, and now it’d compile ) Here are some more places where the same or similar things have come up: Allow a trailing `..` in a stru…

[Pre-RFC] Partially Initialized Types

there’s been a lot of talk about &uninit references, MaybeUninit, placement-new… I’d like to propose an alternative to all of them: Partially Initialized Types. They’re, arguably, the cleanest approach to all of this. Consider types: struct Foo { a: i32, b: i32 } struct Bar { a: i32, b: Foo } Then, we can have: let x: Bar(b(a)) = Bar { b: Foo { a: 1 } }; However, passing these to functions is mostly pointless: fn foo(x: &mut Bar()) { // can't do anything with x here } foo(x); // but c…

RFC: Structural Records

In fact Rust used to have a similar facility called structural records, but they were removed

Remove structural records