We were talking about this in a recent design meeting, and we decided to move away from the <T> generic style. Instead, we'd list off the types in a name:value style, closer to a call:

table(name: string, age: int)

or

record(name: string, id: string)

or

list(int)

We talked a bit about making the last one [int] but I think decided to go with the readable names for now.

Codecov Report

Merging #8914 (5131248) into main (a1b7261) will decrease coverage by 0.34%.
The diff coverage is 86.62%.

@@            Coverage Diff             @@
##             main    #8914      +/-   ##
==========================================
- Coverage   68.57%   68.24%   -0.34%     
==========================================
  Files         636      636              
  Lines      101772   101881     +109     
==========================================
- Hits        69788    69526     -262     
- Misses      31984    32355     +371     

i think this is easy to fix! let me do that

Nice, I'm glad it cleans up some code, too.

Wrapping these shape decls for table and record in parens seems odd compared to def <name> [ <arglist> ]. Why should these delimiters be different?
But rather than change the parens to square brackets on shape decls, I'd go the other way and use parens in def arg decls. I've always thought the square brackets in this context were non-industry-standard. I get that it's evocative of a list, but still...
Is it just too late to change?

can't wait to see these new annotations in nushell @1Kinoti 🤩

Wrapping these shape decls for table and record in parens seems odd compared to def <name> [ <arglist> ]. Why should these delimiters be different? But rather than change the parens to square brackets on shape decls, I'd go the other way and use parens in def arg decls. I've always thought the square brackets in this context were non-industry-standard. I get that it's evocative of a list, but still... Is it just too late to change?

Not sure what you're asking, but if you are asking about reusing delimiters, you wouldn't want the same delimiter for both the argument list and the type parameters to the types. Readability improves by using two separate ones[foo: Record[name: string, id: int]] is much harder to read than [foo: Record(name: string, id: int)]

Let me take the broader question up on Discord, it's not a problem with this PR specifically. It's great for Nu to be able to annotate record and table shapes!

I remember having this discussion about this change but what I don't remember is why we changed from <> to (). Seems like list<int> is more intuitive than list(int) since the parentheses makes it looks like list() is a function with the int parameter.

Also, since we allow optional parentheses in custom command definition, like:

def ok (rec: record(name: string)) { $rec }

i'm not sure that's more readable than this below. It kind of feels the same.

def ok [rec: record[name: string]] { $rec }

But

def ok (rec: record<name: string>) { $rec }

and

def ok [rec: record<name: string>] { $rec }

both still read as rec is the parameter with a type of record<name: string>.

I'm not willing to die on this hill, but I think the "alligators" <> are more intuitive than the parentheses, in this use case.

Update: One big thing that I forgot to mention was that we've been considering adding function calling that looks like command(param). So, this is the main reason why I'm in the list<int> camp.

I'm not willing to die on this hill, but I think the "alligators" <> are more intuitive than the parentheses, in this use case.

i agree with this 👍
maybe more: "i think the () are less intuitive and look like function calls" 😋

I think the reason we're going back and forth on this is that we lack an agreed overarching model for the language.
Do we want NU to "just look right" as a thing unto itself? or should it "remind users of" some other language, and, if so, which (language or languages)?
For now, I say, ship it! We have a working feature (modulo the final syntax), and the strong possibility that resolution of the syntax question will require more wide-spread changes when it comes. Might as well get the benefit of the (stronger typing) behavior in the meantime.

Just to 👍 what @fdncred said - after we talked about it in a recent design meeting, we realised that that () for the type parameter would look too confusing if folks used the alternate parameter syntax def foo (x: list(int)) { ... }

We've been talking about also adding an alternative call syntax like foo([1, 2, 3]) so that might encourage more folks to use the () syntax.

As a result, seems like <> is our best bet for the type parameter syntax for now.

Sorry about going back and forth.

and using <> back might have the side-effect of making this PR not a breaking-change 👍

Just to +1 what @fdncred said - after we talked about it in a recent design meeting, we realised that that () for the type parameter would look too confusing if folks used the alternate parameter syntax def foo (x: list(int)) { ... }

We've been talking about also adding an alternative call syntax like foo([1, 2, 3]) so that might encourage more folks to use the () syntax.

As a result, seems like <> is our best bet for the type parameter syntax for now.

Sorry about going back and forth.

no problem @jntrnr , let me do that

Thanks @1Kinoti. We're close to a release (April 25), and we have a 2 day freeze before that day, so we probably won't land this until after that. I'd like to have more than a day to test it. Thanks again for all your support and PRs!!!

Thanks @1Kinoti. We're close to a release (April 25), and we have a 2 day freeze before that day, so we probably won't land this until after that. I'd like to have more than a day to test it. Thanks again for all your support and PRs!!!

you're welcome @fdncred! after the release it is

@1Kinoti Thanks again. I'm loving this change!

can't wait to play with them 🤩