Keep typealias and disallow attributes on "nested" types

[bernardnormier]

Currently, slicec substitutes typealias where they are used. So if you write:

typealias StringSet = [cs::type("HashSet<string>")] Sequence<string>

interface Example {
    op(v : Sequence<StringSet>
}

For the code generator, these definitions are identical to:

interface Example {
    op(v : Sequence<[cs::type("HashSet<string>")] Sequence<string>>
}

(which is an allowed syntax)

Proposal

Remove this eager substitution of typealias, and disallow attributes on nested types when defining anonymous types. In other words:

interface Example {
    op(v : Sequence<[cs::type("HashSet<string>")] Sequence<string>> // syntax error with my proposal
}

In order to achieve the desired result, you have to use a typealias, as in:

typealias StringSet = [cs::type("HashSet<string>")] Sequence<string>

interface Example {
    op(v : Sequence<StringSet>
}

This limits where attributes are valid to:

• named type (such as struct)
• other named constructs (such as interface and typealias)
• type references in fields and parameters (FieldTypeRef?)

With this proposal, the normalized name of an anonymous type becomes a unique, unambiguous ID. For example: Sequence<Sequence<Dictionary<string, MyModule::HashSet>>> always designates the same attribute-free anonymous type.

[InsertCreativityHere]

Remove this eager substitution of typealias

Yes, we went back and forth on this in the past (whether or not type-aliases should be "transparent" or not).
I'm fine with removing this substitution, since it's useful for languages which support typealiases.
Ever the devil's advocate, there are two downsides to this though:

1. It makes all our code more indirect. Anywhere which uses a type is no longer "shallow", but has to become capable of traversing an arbitrarily long chain of aliases. Doable, but adds complexity and requires abstractions.
2. For languages which lack typealiases (C#), they will have to perform the substitution themselves.
   This patching is non-trivial to implement.

I tried to find our old discussions about this, but couldn't : v/

---

disallow attributes on nested types when defining anonymous types

I think I have a compromise which accomplishes our goal without needing this.
Because ideally, I'd prefer to not have this restriction. It makes Slice less consistent, and makes users add typealiases unnecessarily.

We need this restriction so we get unique string ids for anonymous types, which unifies how you reference types on-the-wire.
Currently, we have a (lame) enum which stores a varuint62 which uniquely identifies the type in anonymousType.

SubProposal

We keep everything the same in your PR, but instead of having type-ids be of the form "Sequence<...>" for anonymous types, we use an index: "5".

Yes, we're deleting Sequence<AnonymousType> (glad to see it go), but these anonymous types are just getting moved into Sequence<Definition>. They'll still live in a sequence, so they still have a stable index.

This means we don't need to generate a stringified type-id for these types, so we're free to not care if it has attributes,
it gives a stronger uniqueness guarantee than the stringified-ids do,
it means we don't need to store the typeId on the anonymous types (we know their index by virtue of decoding them),
and most important: it will save us many bytes on the wire! <partial_sarcasm/>

The IDs for anonymous types don't really matter for code-gen, just for being able to decode the definitions you receive.
So, as long as they're unique, the exact representation doesn't matter.

Also, obviously, using a number means it can never conflict with a user defined type, nor primitive. Just like how the originals couldn't either (since < can't appear in identifiers).

[bernardnormier]

It makes Slice less consistent, and makes users add typealiases unnecessarily.

It would be helpful if you could expand on this topic because I think my proposal makes Slice simpler/better.

Take:

typealias MyStruct = [...] SomeStruct

struct S {
   x: [...] SomeStruct
}

the attribute applies to the type in the Typealias descriptor or Field descriptor, not to the type itself.

With my proposal, the same would be true for anonymous types. I don't want anonymous types to have attributes - in simple cases, they can't have / shouldn't attributes since the attributes stay with the Field/TypeAlias. Allowing attributes only for nested anonymous types sounds over the top to me. What's the use-case? Why is it "more consistent"?

[InsertCreativityHere]

Why is it "more consistent"?

About consistency: right now the rule in Slice is:
When you reference a type, you can put attributes in front of it, and they apply to that type.
With your proposal, we would be carving out an exception to this rule:
... unless the type is nested, in which case attributes are invalid.
With your change, they would only be valid in some cases, but not in others. Whereas right now, they're always valid. This is less consistent from a language design perspective.

TL;DR It feels weird that attributes only work on sequences (etc.) in some cases, but not others.

---

What's the use-case?

The use case is the same use case as wanting to put attributes on a non-nested sequence. Sometimes you have a collection, and you don't want the default mapping. This is true whether or not the collection is nested.

If you don't think there is a use case for this, then we shouldn't be allowing attributes on type-alias types either. This proposal doesn't change what you can accomplish with Slice; it just makes you introduce a typealias to express X... whereas the current design lets you express the same thing without needing an alias.

TL;DR It doesn't change what you can express with Slice, it just makes it harder to express that thing.

---

the attribute applies to the type in the Typealias descriptor or Field descriptor, not to the type itself.

I think I'm understanding what you're saying. But it took me some time to comprehend. Right now the lines between "this attribute goes on a field" and "this attribute goes on a type" are crystal clear, and reflected in the structure. Your proposal blurs that line by storing all attributes on the field itself.

It also means more 'tag(N) : Sequence' fields in more places, which is annoying for bootstrapping.