Opaque string types

[DeadMG]

I've got an opaque string type. We basically use this type for things that are strings under the hood, but shouldn't be interchanged with actual free text strings- for example GUIDs. We also use the nominal type checking hack with the private void property to nominally type check them.

We have a problem, though, which is that the compiler won't permit them as dictionary keys.

Can we permit a type annotation or something to say that the type is really a string or integer under the hood and should be permitted as a dictionary key?

[RyanCavanaugh]

Duplicate of #5599

[DeadMG]

The opaque type is not an intersection type, since we do not want to permit assigning a Guid to a string, which the intersection type does permit. And we also do not want to permit the vast majority of string members to be callable on a Guid.

[RyanCavanaugh]

Maybe you can post some code?

[DeadMG]

It currently looks like this:

// Construct Guids using Guid.fromString()
abstract class Guid {
    private nominal: void;

    // Expose method from actual runtime String class.
    abstract toString(): string;

    static fromString(value: string): Guid {
        return <any>value;
    }

    static toString(value: Guid): string {
        return <any>value;
    }

    static emptyGuid(): Guid {
        return Guid.fromString("00000000-0000-0000-0000-000000000000");
    }

    static isNullOrEmpty(value: Guid) {
        return _.str.isBlank(Guid.toString(value)) || value === Guid.emptyGuid();
    }
}

Guid.fromString is an evil method that we use for tests but shouldn't really. The return types from our web services specify Guids to match guid types on the server; they're actually serialized as strings. Our client really shouldn't be doing any interesting processing on Guids at all- just passing them around.

So basically, the nature of Guids as actually strings at runtime is completely hidden from the user, as both outgoing and incoming DTOs define them as Guids, and we want the strongest of checking between Guids and strings- they are completely not interchangable in any way.

But it would also improve the typing of our code if we could use them as dictionary keys, like we can on the server.

[mhegazy]

I would refer to this as "tagged" types. basically a sub type of string, that is only assignable from values of the same type, but otherwise behaves like a string. Tagged types are just a form of nominal typings. there is a long discussion about this in, #4895 and you can see how in the TS compiler code bases we use a similar approach in https://github.com/Microsoft/TypeScript/blob/master/src/compiler/types.ts#L8.
I think this issue is better handled by #202

[DeadMG]

Like I explained to the other guy, they're not the same as we do not permit assignments the other way either, or any members. In fact, in the type system, Guid and string are completely and utterly unrelated.