Skip to content

[simple-linked-list] Add missing initialValues field#2645

Merged
kotp merged 1 commit intomainfrom
senekor/trslomlyrnpu
Apr 15, 2026
Merged

[simple-linked-list] Add missing initialValues field#2645
kotp merged 1 commit intomainfrom
senekor/trslomlyrnpu

Conversation

@senekor
Copy link
Copy Markdown
Contributor

@senekor senekor commented Apr 15, 2026

Templating languages that distinguish between undefined and empty list
will crash out on this missing field, or force the template author to
handle the field's absence explicitly.

Templating languages that distinguish between undefined and empty list
will crash out on this missing field, or force the template author to
handle the field's absence explicitly.
@senekor senekor force-pushed the senekor/trslomlyrnpu branch from ad8f8c9 to 490f9ea Compare April 15, 2026 05:09
@kotp kotp merged commit 76ee5b7 into main Apr 15, 2026
7 checks passed
@kotp kotp deleted the senekor/trslomlyrnpu branch April 15, 2026 06:44
@IsaacG
Copy link
Copy Markdown
Member

IsaacG commented Apr 18, 2026

This actually causes the Go generator to swap []int(nil) (a null slice) for []int{} (an empty slice) which is less idiomatic :D Now I'm debating trying to add something to the test to force things back to nil.

@senekor
Copy link
Copy Markdown
Contributor Author

senekor commented Apr 18, 2026

There are several other test cases with an empty initialValues, so the problem should've existed already?

Maybe off topic here, but I am curious why nil is more idiomatic :) I assume that []int{} is optimized not to cause an allocation. When I was using Go a couple years ago, "empty" and "nil" objects being different things was an unpleasant source of bugs.

@IsaacG
Copy link
Copy Markdown
Member

IsaacG commented Apr 18, 2026

There are several other test cases with an empty initialValues, so the problem should've existed already?

Yup. Though it's not a problem so much as not following accepted style.

Maybe off topic here, but I am curious why nil is more idiomatic :) I assume that []int{} is optimized not to cause an allocation. When I was using Go a couple years ago, "empty" and "nil" objects being different things was an unpleasant source of bugs.

Go encourages the "zero value" to be useable as is. You should be able to use the nil slice interchangably with the empty slice for most things in Go.

See https://google.github.io/styleguide/go/decisions#nil-slices and https://github.com/pthethanh/effective-go#declaring-empty-slices

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants