experiment: newtype

[Kamirus]

No description provided.

[crusso]

One thing that might be problematic with this approach.

Assume we allow new types in stable variable signatures (e.g. for maps).
When checking stable variable compatibility, we basically parse and type check the two signatures separately and then compare their fields pointwise

I think the new types in the left and right signatures will always receive different stamps, and thus be considered different, even when you want them to be the same. I don't think there will be any easy way to determine which ones should be regarded the same and which one should be regarded as distinct.

I think this problem would not arise if we just added a new structural type constructor, pairing a name (not a stamp) with a type and requiring equality of names and related content when relating two types.

@christoph-dfinity agree?

[crusso]

Hmm, I guess that might fix the problem I noticed with signatures. Feels a bit odd though.

[crusso]

At least it would mean moving from unbranded map to branded map would not be a breaking change, but I'm not sure that's a good enough motivation.

[christoph-dfinity]

A similar question would be if we want newtypes to appear in the Candid encoding. You could feasibly represent them as single element records/variants. But I don't know if that's desirable?
I could think of a few places where they'd make good documentation time : record { #milliseconds : Nat } is a lot more descriptive than time : Nat.
Another use-case these are often used in is to mark sensitive data that shouldn't make it into logs/api responses in clear text. There you'd also prefer to not silently turn a #password : Text into Text at the API boundary.