Is `.base` permitted as a struct member? Is it the same as `.r#base`? about carbon-lang HOT 6 CLOSED

Option 4 seems good.

Regarding option 5, a few things I'd suggest considering before adopting the noted implicit flattening/nesting conversions via struct update syntax:

1. For background, considering C++, I think this is a change in behavior which may lead to different results. .base gives a syntax to update the parent without confusion about whether the field is on the child, which is not in C++ and would likely be helpful; still, there's a distinction between base and child structs. Maybe there's some way to make struct initialization work, but the naive way doesn't:

   struct A { int x; };
   struct B : public A { int y; };
   // Error: field designator 'x' does not refer to any field in type 'B'
   B c = {.x = 0, .y = 1};
   
   struct D : public A { int x; int y; };
   // Valid C++ code.
   D e = {.x = 0, .y = 1};
   

   https://cpp.compiler-explorer.com/z/evT88P8qT

2. In most cases of name ambiguity, I would expect ambiguities to be resolved by adding qualifiers. In this case though, ambiguities are resolved by specifying more things: the original designated name remains. This feels a little unusual to me.

   // An error due to ambiguity in the `.x` initialization?
   var a: {.base: {.x: i32}, .x: i32} = {.x = 0};
   // Now unambiguous.
   var b: {.base: {.x: i32}, .x: i32} = {.base = {.x = 0}, .x = 1};
   

3. What about classes and tuples? In classes, making base optional seems like it would be similar, although it may raise concerns about type safety. In tuples, I think it'd already been discussed and the decision was to treat nesting as requiring explicit flattening, not an implicit conversion.

   For example:

   // The struct literal example:
   var a_struct: {.base = {x: i32, y: i32}, z: i32} = {.x = 1, .y = 2, .z = 3};
   var b_struct: {.x: i32, .y: i32, .z: i32} = a_struct;
   
   // Similar in classes:
   class BaseT { var x: i32; var y: i32; }
   class ChildT { extend base: BaseT; var z: i32; }
   var a_class: ChildT = {.x = 1, .y = 2, .z = 3};
   var b_class: {.x: i32, .y: i32, .z: i32} = a_class;
   
   class FlatT { var x: i32; var y: i32; var z: i32; }
   var c_class: FlatT = a_class;
   
   // Similar in tuples:
   var a_tuple: ((i32, i32), i32) = (1, 2, 3);
   var b_tuple: (i32, i32, i32) = a_tuple;
   

Regarding the with keyword in var xyz: auto = xy with {.z = 3};, I think that is more explicit, and so doesn't have the same concerns as implicit casts, although name ambiguities may still be odd to resolve [e.g. var a: {{.base: {.x: i32}, .x: i32} = val with {.base = {}, .x = 3};].

from carbon-lang.

FWIW, I also like option 4.

Options 1-3 seem likely to end up with some amount of friction, whereas option 4 seems to really elegantly express the range of things we want in struct literals and provide important functionality for initializing base classes.

We can always revisit option 5 if/when we have motivation and some ways to deal with both the issues raised in the original description and by Jon.

from carbon-lang.

I think option 4 is my preference here -- it gives a consistent behavior for the name base in classes and structs, seems (at least a little) useful for structs independent of the class initialization use case, and fits nicely into the class initialization use case.

Option 5 seems a little too implicit and do-what-I-mean-ish to me, and a more explicit struct update syntax seems like a better fit for Carbon's design aesthetic.

from carbon-lang.

Options 4 and 5 are the most tempting to me

from carbon-lang.

I think we are only really supporting struct -> class conversions, not the other direction.

from carbon-lang.

Let's call this decided with option 4 -- seems we have enough consensus among leads and no strong objections. And the comments above have lots of good points of rationale, including from leads.

from carbon-lang.