Proposal: inferred struct field type via default value

[fengb]

I think the fields with default values could be inferred in the same way as variables:

const ZeeAlloc = struct {
    backing_allocator: *Allocator,

    free_lists: [size_buckets]FreeList = [_]FreeList{FreeList.init()} ** size_buckets,
    page_size: usize = page_size,
    allocator: Allocator = Allocator{
        .reallocFn = realloc,
        .shrinkFn = shrink,
    },
}

// compare with

const ZeeAlloc = struct {
    backing_allocator: *Allocator,

    free_lists = [_]FreeList{FreeList.init()} ** size_buckets,
    page_size = usize(page_size),
    allocator = Allocator{
        .reallocFn = realloc,
        .shrinkFn = shrink,
    },
}

[dimenus]

Does this make it harder to easily identify what is a decl and what is a regular assignment? Unlike in func / global scope there's no keyword to make it easily identifiable.

[fengb]

Good point. My half-baked idea — prepend the dot like regular struct init:

const ZeeAlloc = struct {
    backing_allocator: *Allocator,  // possibly always prepend?

    .free_lists = [_]FreeList{FreeList.init()} ** size_buckets,
    .page_size = usize(page_size),
    .allocator = Allocator{
        .reallocFn = realloc,
        .shrinkFn = shrink,
    },
}

[tiehuis]

I don't know about this proposal. I think adding a new way of
performing default-field initialization would lead to a mismatch in style and
wouldn't be beneficial. I also suspect that more complicated default-field
initializations (e.g. structs, arrays) which this would improve the most, may
not be common enough to be a compelling reason. This is just an assumption on
my part after a bit of use, though.

Specifically about the style-mismatch, this brings up implicit casting vs.
explicit type parameters. There is an existing proposal about adjusting the
implicit-casting syntax which may or may not reduce the impact of this
proposal: #1757. There are actually some other related things in that issue
but I'll leave them for now.

struct {
    a: usize = 5,
    b: ?Foo = null,
}

struct {
    a = usize(5),
    b = (?Foo)(null),
}

The latter style of nullables is rarely used currently. You could argue that
you could mix and match styles, but we usually "prefer one way to do things"
where reasonable.

[fengb]

The style mismatch already exists with regular variable declarations:

var a: usize = 5;
var b = usize(5);

struct {
  a: usize = 5,
  b = usize(5),
}

I just think the semantics are similar enough to warrant similar syntax.

[mikdusan]

On the styling, I've been musing about dot-syntax to differentiate between field vs. namespace decls and dropping "comma" with some added benefits:

1. replace a: u32, field decl syntax with .a: u32;
2. add field decl inferral syntax: .b = false;
3. idiomatic init() routines now have a chance to self-reference values/addresses during copy-elision return

const Foo = struct {
    .some_flag = false;
    .arena_storage: std.heap.ArenaAllocator;
    .arena: *std.mem.Allocator;

    fn init(backing: *std.mem.Allocator) Foo {
        return Foo{
            .arena_storage = std.heap.ArenaAllocator.init(backing);
            .arena = &.arena_storage;
        };
    }
};

this has the consequence of... changing how field initialization looks (commas now become semicolon):

var a = Car{ .a = 1; .b = 2; .c = 3; };
var b = Car{ .a = 1; .b = 2; .c = a+b; };