Notation for structs

[jyasskin]

When writing a non-tuple struct value in another spec, it'd be nice to have a notation for it. There are several options, but I haven't gone looking through other specs to figure out which ones are already used.

[domenic]

The original idea was (x: foo, y: bar), but we cut it from the PR that added structs because nobody seemed to be using it any literal notation at all yet. What are your thoughts?

[jyasskin]

I like (x: foo, y: bar). I'm suggesting an algorithm-local struct in w3c/webauthn#427, where it takes too many words to lay out the names in prose.

[jyasskin]

A nameless tuple would work too, but I'd rather name the fields.

[jyasskin]

I turned out not to suggest the struct in my review after all, so if you want to wait until there's a real use, that's fine.

[equalsJeffH]

I'm curious, how do structs, as defined, functionally differ from maps and Records?

[domenic]

Structs have a well-defined set of keys. It's the difference between hashmap<k, v> or hashmap<string, value> and struct foo { type1 field1; type2 field2; type3 field3; } in traditional programming languages.

[equalsJeffH]

thanks. to test my understanding, is this correct?

Structs differ from maps and Records in that a struct has a well-defined and immutable set of keys.

..? if so, perhaps it ought to be added to infra's Structs section ?

It seems there is no present way to formally declare something of type struct using WebIDL ?

[domenic]

Well, we won't mention records, as Infra sits below Web IDL.

For the same reason, struct is not a Web IDL type; it's a type that's useful in writing specifications, often backing some other structure (like an interface).

I'm not sure saying "Structs differ from maps in having a well-defined and immutable set of keys" is useful given that the very definition of structs is

A struct is a specification type consisting of a finite set of items, each of which has a unique and immutable name.

In that case your sentence reduces to "structs differ from maps in being structs".

[equalsJeffH]

doh.

A struct is a specification type consisting of a finite set of items,...

is the set of items actually "finite and immutable" ?

[annevk]

@equalsJeffH the items are mutable, the names associated with them are not.

[annevk]

@tabatkins brought this up the other day. A syntax that might work is

(name → value, name2 → value2)

which makes them look similar to tuples, except that the names of the items are visible and can appear in any order.

As discussed in whatwg/whatwg.org#396 not all structs necessarily want a literal syntax and we should make note of that if we decide to add syntax.

[domenic]

I'm happy to add this. Any thoughts on (name → value, name2 → value2) vs. (name: value, name2: value2)? The former is more like an ordered map, which could be good or could be bad.

[annevk]

I'm happy with either. The latter involves less copy-and-pasting...

[tabatkins]

I think it's good to be consistent between the syntaxes if possible; structs and maps are very similar and having their key/value separator be different seems confusing.

(But I do like the colon over the arrow, same as @annevk; maybe we could switch (or at least allow) maps to use colons as well?)

[tabatkins]

That said, is there a big reason not to just use the map literal syntax here? We already let map literal syntax be used for IDL record when it's clear from context what's desired; this is Yet Another KV syntax and can probably lean on the same thing? I don't think there's any real chance of confusion.

[annevk]

Well, for maps the names are essentially values. For structs the names are immutable identifiers. That is a bit different at least and would visually show they are different, albeit very subtly.

Also, maps and IDL records are conceptually very much the same thing. Just like lists and IDL sequences. Maps and structs are not.

[tabatkins]

Well, for maps the names are essentially values. For structs the names are immutable identifiers. That is a bit different at least and would visually show they are different, albeit very subtly.

Right, they're different, but do we need to specially guard that distinction via syntax? Do we believe it would cause confusion to not have them syntactically distinguished? If someone is going to write spec text that builds a struct with arbitrary keys, do we think that seeing () vs «[]» is the thing that's going to make them stop and realize they're doing something wrong? (I'm not suggesting letting maps and structs be interchangeable as values, just that you can use the same literal syntax to say things like "the struct «[ "a" → x, "b" → y ]»" as distinct from "the map «[ "a" → x, "b" → y ]»".)

[domenic]

Do we believe it would cause confusion to not have them syntactically distinguished?

I would be confused...

[tabatkins]

So you find "the fooStruct «[ "a" → x, "b" → y ]»" to be confusing to read?

[domenic]

Yes.

[annevk]

I think it would be especially weird to markup the names as if they are strings. They're not.

[tabatkins]

All right, I disagree but I'm outnumbered. ^_^ In that case, still keeping consistent kv separation characters with map literal is good imo, so my vote goes to (foo → val, bar → val)