Pre-RFC: Partial Borrow Syntax Sugar

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.

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?

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

1 Like

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.

2 Likes

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.

This exactly.

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

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.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.