Pre-RFC: Partial Borrow Syntax Sugar

[scottjmaddox]

I woke up with this idea this morning. It is still very much a work in progress, but I want to get the idea out there to get some feedback and let the wider community iterate on it.

rendered

Edit: updated rendered link to point to feature branch.

[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

[RustyYato]

Also, before you create a pull request, I highly recommend that you put this on a separate branch from master. I made this mistake with my own RFC, and it is a mess.

[scottjmaddox]

Yato, thanks for your response. I may be wrong, but I believe that this syntax for anonymous structs is perfectly unambiguous, as long as it only occurs in the place of a function argument type. Perhaps this requires an undesirable amount of contextual parsing, though.

Could you please provide a link to the "views" proposal your discussing? I'm not familiar with it. Or are you just talking about manually creating partial borrow structs and manually destructuring on function call?

Based on your description, it sounds like views require explicit naming. My main motivation for allowing anonymous structs here is that calling the function/method is cruft free, e.g. v3.xy_mut().

Also, if you need to use it in multiple places, you will have to name it anyways.

Not if this is implemented in the compiler frontend, where duplicate anonymous structs could be deduped.

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

Great question! That would certainly be undesirable. As a first pass, I think it would be necessary to require that the function has the same or less visibility than the least visible field. I'm not sure if anything more clever is possible, but even with this requirement I believe this syntax would be a great improvement over manually defining and using partial borrow structs.

[RustyYato]

@scottjmaddox

Or are you just talking about manually creating partial borrow structs and manually destructuring on function call?

This exactly.

@scottjmaddox

Also, if you need to use it in multiple places, you will have to name it anyways.

Not if this is implemented in the compiler frontend, where duplicate anonymous structs could be deduped.

What I mean by this is the following

struct Point { x: f32, y: f32, z: f32 }

impl Point {
    fn translate_x(self: struct { x: &mut f32 }, diff: f32) { self.x += diff; }

    fn get_x(self: struct { x: &mut f32 }) -> &mut f32 { &mut self.x }
}

I know this example is trivial, but it shows the point. I have x in both places, and only x, so how do I extract it out? I want to reduce repetition. (Not being able to extract it out is fine, I just wanted clarification).

[scottjmaddox]

Yato, thanks for the clarification. As a first pass, I think it would be necessary to repeat the field members. If anonymous structures where ever added back as first class types, perhaps you could do something like type XRefMutF32 = struct { x: &mut f32 };, but that would be going past syntax sugar.