Proposal: Typed Aliases/Wrapper Structs

[HaloFour]

In any particular domain it's pretty common to have bits of data that are represented by simple/primitive types such as int or string. Unfortunately storing this domain data in these data types also loses that type information and type safety. This can result in accidentally passing a customer ID in place of an order ID.

One common approach to solving this problem is to declare a wrapper so that you can safely encapsulate the value in a type-safe container. This nicely addresses the issue of accidentally passing the wrong value. But the problem with this approach is that you immediately lose the ability to compare the equality of the wrapper type or use as a key within writing a lot of additional boilerplate.

So make it easier to write these wrappers I propose a way to declare a "typed alias" which will generate all of the necessary boilerplate. This boilerplate would include:

1. Underlying readonly field.
2. Constructor
3. GetHashCode/Equals/ToString
4. Explicit conversion operators to/from the underlying type
5. Implementation of the following interfaces
   1. IEquatable<T> for the wrapper type
   2. IStructuralEquatable
6. Equality operators
7. Debugger display

Here are some examples:

// not settled on this syntax
public struct CustomerId : string;

// generates something like

public struct CustomerId : IEquatable<CustomerId>, IStructualEquatable {
    private static readonly IEqualityComparer<string> EqualityComparer = EqualityComparer<string>.Default;
    private string Value;

    public CustomerId(string value) => Value = value;

    public override bool Equals(object obj) =>
        obj is CustomerId other ? Equals(other) : false;

    public override int GetHashCode() => EqualityComparer.GetHashCode(Value);
    public override string ToString() => Value.ToString();

    public bool Equals(CustomerId other) => Equals(other.Value);

    public static explicit operator CustomerId(string value) => new CustomerId(value);
    public static explicit operator string(CustomerId wrapper) => wrapper.Value;

    public static bool operator ==(CustomerId x, CustomerId y) => x.Equals(y);
    public static bool operator !=(CustomerId x, CustomerId y) => !x.Equals(y);
}

The developer may add their own members into the body of the wrapper type:

public struct CustomerId : string {
    public bool IsPartner => Value.StartsWith("P");
}

If any of the generated members conflict with user-written members, the user written members take precedence and those generated members are skipped. Through these two mechanisms the developer can customize the behavior of the wrapper type.

public struct CustomerId : string {
    static CustomerId() {
        // override equality comparer to ignore case
        EqualityComparer = StringComparer.OrdinalIgnoreCase;
    }

    public CustomerId(string value) {
        // validate value here
        this.Value = value;
    }
}

And yes, this could probably easily be accomplished via source generators.

[bondsbw]

Seems like a single-value record. What's different?

Would we want to allow wrapping multiple values?

public enum Suit { Diamonds, Hearts, Clubs, Spades }
public enum Face { Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten, Jack, Queen, King, Ace }

public struct PlayingCard : (Suit, Face);

[bondsbw]

I'll answer after re-reading, one difference is built-in comparison/conversion with the underlying type.

Would this have an advantage over extending records to provide that boilerplate?

[bondsbw]

I assume the conversion/comparison type would be a tuple if there are multiple values. One direction of the conversion would be covered by a deconstructor (mentioned in #1204).

[HaloFour]

@bondsbw

Seems like a single-value record. What's different?

More transparency with the underlying type which really wouldn't be possible with general purpose records so easily. For example, I think it'd be useful to compare a CustomerId directly with a string. Beyond that I think that there is a lot of overlap, but with the additional data class and named tuple proposals out there I think that the future of records is a tad murky. As I'd like to see case classes become a part of the language I thought I'd throw my hat in the ring with this proposal but if it got subsumed into one of the other proposals I'd be happy.

Would we want to allow wrapping multiple values?

I think that wrapping a tuple would work well. Perhaps the C# compiler could also emit a proper deconstruct method as well. There might be a lot of overlap between this and named tuples.

[CyrusNajmabadi]

Implementation of the following interfaces

Why not have teh wrapper type implement all the interface of the wrapped type?

[CyrusNajmabadi]

public override string ToString() => _value?.ToString() ?? "";

Not a fan of the null-behavior not propagating into the wrapper. A null-string throws on things like .ToString. I would expect the wrapper to throw as well.

[CyrusNajmabadi]

Conversion operators
Explicit operator from the underlying value to the alias which invokes the constructor
Implicit operator from the alias to the underlying value

I feel like i would far prefer either:

1. explicit operators in both directions.
2. implicit to take a value and wrap into the new type, but explicit to go back to the underlying value.

And i think i far prefer '1'.

[HaloFour]

@CyrusNajmabadi

Why not have teh wrapper type implement all the interface of the wrapped type?

That's an interesting idea. For cases where the wrapped type implements a generic interface where the wrapped type is a generic type argument would it emit an implementation for both the wrapped type and the wrapper type? Or should interfaces like IEquatable<T> and IComparable<T> be treated specially? I'd be a little concerned that this might get weird, but it could make the wrapper type more useful.

Similarly would it make sense to propagate versions of any comparison operators? I think it would be useful to be able to compare a wrapper directly to an instance of the wrapped type:

CustomerId custId = ...;
if (custId == "12345") { ... }

Not a fan of the null-behavior not propagating into the wrapper.

That's fair.

I feel like i would far prefer either:

1. explicit operators in both directions.
2. implicit to take a value and wrap into the new type, but explicit to go back to the underlying value.

And i think i far prefer '1'.

I was trying to describe 2 in a roundabout way. I thought it might make it easier to use the wrapper type in situations excepting the wrapped type as such a conversion should be type safe, but I can see arguments both ways here. I'll mention both approaches as an open question.

[bbarry]

What if it was possible that these types didn't exist as far as the runtime was concerned?

I'm imagining C# would have some sort of "Aliased" types alongside Value types and Reference types.

Within C# it would work like dynamic does today where if you do something with it besides cast to an underlying type it stays as whatever type you say it is. However instead of how dynamic allows you to do whatever dynamic thing, this would only allow you to do whatever the underlying type was.

some pretend syntax:

public alias CustomerId : string;
public alias AnotherId : string;

compiles as:

[UnderlyingType(typeof(string))]
public sealed class CustomerId {}
[UnderlyingType(typeof(string))]
public sealed class AnotherId {}

in usages:

// 1. allow implicit casts to the type:
public CustomerId Foo() => default;

// 2. explicit cast required here:
public string Bar(CustomerId id) => (string)id;

// 3. no conversion exists between two alias types that share an underlying type:
public bool Baz(CustomerId id, AnotherId id2) => id == id2;

// 4. but you could cast and have the compiler figure out what you wanted to do:
public bool BazWorks(CustomerId id, AnotherId id2) => (string)id == id2; 
// works now because implicit string -> AnotherId is valid 
// and operator==(AnotherId, AnotherId) works by definition of alias types 
// since the underlying type is string and it is defined there

// lowers to:
[Alias(typeof(CustomerId))] public string Foo() => default;
public string Bar([Alias(typeof(CustomerId))]string id) => id;
//nothing for 3rd because of compile error
public bool BazWorks([Alias(typeof(CustomerId))] id, [Alias(typeof(AnotherId))] id2) => id == id2; 

Not sure if an identity conversion makes it through the compiler, I suppose it doesn't really matter if those exist in the lowered form or not.

The aliased type would behave as if all members on the underlying type with parameters or return values matching the underlying type were instead the alias type. An implicit conversion would be defined from the underlying type to the alias type in namespaces where the alias type was in scope. An explicit conversion from the alias type to the underlying type would also be defined.

This might be a bit annoying with extension methods explicitly defined on underlying types but meh...

[HaloFour]

@bbarry

What if it was possible that these types didn't exist as far as the runtime was concerned?

The JIT is already pretty decent at optimizing away single-field structs used as wrappers.

I'd rather have proper nominal types that can be used as proper nominal types in signatures and everywhere else than something that is erased by the compiler and faked by the runtime.

[theunrepentantgeek]

I'm a very big fan of so-called semantic types and I'd love to see C# make it easier to declare these (and thus encourage adoption). However, I'm not convinced that this proposal is a good way to achieve what's needed.

But the problem with this approach is that you immediately lose a lot of the functionality of the underlying type and to restore that functionality requires writing quite a bit of boilerplate.

This is something I like - it gives me control over what's exposed. For example, I could create an InvoiceId based on wrapping an int - but adding two InvoiceId values does not make sense. Depending on the business domain, ordering (< <= > >=) might not make sense either.

Implicit operator from the alias to the underlying value

I've implemented implicit casts on a number of semantic types in non-trivial codebases - and the result was significant pain. If a PartId has an implicit conversion to int, the compiler won't catch the case where it's passed into something that is most definitely not a part id.

I toyed for a while with having a .Value or a .AsInt property, but I've now settled on using an explicit cast as the way to extract the wrapped value and this seems to work well.

For example, I think it'd be useful to compare a CustomerId directly with a string.

I agree that it's useful - but in the business domains I know, an Ordinal string comparison is wrong. Instead, it should be OrdinalIgnoreCase because "C1024" is semantically the same as "c1024" - and this is the kind of detail I'd wrap into the type so that it's consistent across the codebase.

The key is that decisions around the choice of functionality exposed by the semantic type have to originate from the semantics of the type, not accidental details of the implementation.

In the late 1990's, I worked on a system that used a semantic type for vehicle identification numbers (aka VINs). That system broke when new vehicles being imported from Japan showed up with an A in a position that had always been a digit. We were able to quickly release a hotfix based on changing one of the underlying fields from an int to a string.

I expect that if the underlying functionality of an int had been automagically exposed on the VIN datatype, releasing the hotfix would have required a lot more work.

[HaloFour]

@theunrepentantgeek

I agree. The goal isn't to necessarily make the wrapper type behave exactly as the underlying type. It's to make it easier to treat them as single cases based on the underlying value. That in of itself is a decent amount of boilerplate, pretty much everything I've described except maybe for implementations of IComparable<T>. I based the generated members on what F# emits for single-case unions, which are commonly used to solve this problem space in F# today.

I don't want this to behave like inheritance. If CustomerId wrapped string I wouldn't want the umpteen different members of string poking through. I'm even amenable to having the conversion operator back to the underlying type be explicit rather than implicit. That actually makes sense given that's how enums work in C# already.

As for the other concerns, I agree with a number of them and I've been toying around with ways to approach them. I think that it should be possible to include a body for the wrapper type and to add members. I think it's important to be able to define a custom constructor which can enforce validation. I think it would be useful to be able to specify an IEqualityComparer<T>/Comparer<T> instance to properly handle equality for the given domain.

And I'm certainly open to further ideas. Having seen these kinds of types used commonly in F# and Scala I find myself really wanting them. And I've worked on C#/Java projects that have tried to emulate them by manually creating these types which leads to a lot of bloated and repeated boilerplate.

[bbarry]

My vote would be not to do any of this, it has been my experience that there is always additional constraints on such types (for example often string alias types compare case insensitive or can only be ascii or integer keys can only be positive or specific negative values). I was just thinking that there is some precedent for an erased type already in the language. In fact I think a specification for this type could be seen as a generalization of both nullable reference types and dynamic.

Implementing specific interfaces automatically is bad because eventually we probably want to implement other interfaces and that makes two different versions of the compiler not compatible with each other if we did. Which means we would be forever left with the specific interfaces we specified in the first version. That is sorta an issue I have with all of these codegen heavy proposals (records, data classes, this).

[HaloFour]

For the sake of comparison, here's what F# generates:

type CustomerId = CustomerId of string

    [Serializable]
    [StructLayout(LayoutKind.Auto, CharSet = CharSet.Auto)]
    [DebuggerDisplay("{__DebugDisplay(),nq}")]
    [CompilationMapping(SourceConstructFlags.SumType)]
    public sealed class CustomerId : IEquatable<CustomerId>, IStructuralEquatable, IComparable<CustomerId>, IComparable, IStructuralComparable
    {
        internal readonly string item;

        public int Tag { get; }
        public string Item { get; }
        public static CustomerId NewCustomerId(string item);
        internal CustomerId(string item);
        internal object __DebugDisplay();
        public override string ToString();
        public sealed override int CompareTo(CustomerId obj);
        public sealed override int CompareTo(object obj);
        public sealed override int CompareTo(object obj, IComparer comp);
        public sealed override int GetHashCode(IEqualityComparer comp);
        public sealed override int GetHashCode();
        public sealed override bool Equals(object obj, IEqualityComparer comp);
        public sealed override bool Equals(CustomerId obj);
        public sealed override bool Equals(object obj);
    }

[HaloFour]

@bbarry

Implementing specific interfaces automatically is bad because eventually we probably want to implement other interfaces and that makes two different versions of the compiler not compatible with each other if we did.

The interfaces involved in situations like this are 13+ years old and the gold standard in .NET for defining equality. It's not been an issue for F#, where this kind of type is idiomatic.

[quinmars]

I also think that those wrapper structs are very close to single value records.

public struct CustomerId(string Value) {}

I see that the (explicit) casting support and ToString(), is different, although doable with records. Therefor I would go with a similar syntax to records:

public struct CustomerId(string _) {}

or

public struct CustomerId(explicit string Value) {}

the latter could maybe even be extended, to add explicit cast support to multi value records. I don't know if that's useful, though.

[HaloFour]

@quinmars

Related: #1346

Nice, I forgot about that issue. I love my comment. Even then I was pretty sure that source generators weren't going to be unshelved anytime soon.

I also think that those wrapper structs are very close to single value records.

I agree. The reason I decided to bring this issue now is that recent proposals from the LDM have cast some doubt (in my mind) regarding the future of "records". The closest approximation seems to be an extension of and migration from tuples which appears to include extra baggage. As a proponent of DUs and single-value unions for the purpose of type-safe domain wrappers I wanted to capture that here.

[HaloFour]

@juffindell

fair enough, I hadn't considered throwing an exception to be particularly evil but if it hurts the runtime performance and JITting then that might be too high a price to pay. I admit I hadn't been giving the user input comparison as much thought either; I'm not sure if there's a nice non-exceptional way to handle a lifted equality check there.

Looking at F# it seems to avoid a bit of this mess by excluding quite a bit of functionality described here. Single case unions don't have any concept of validation and comparisons are done using the default equality comparer. You can access the underlying value directly and do your own comparisons against it. But that means that the concerns of how equality is determined is on the consumer, not the type itself.

Maybe that's all fine. Maybe this type is trying to do too much. Afterall, enum doesn't have any validation. You're free to cast 42 to System.DayOfWeek all day long and neither the language nor runtime care. Maybe trying to cram validation and custom equality in here doesn't make sense. It doesn't seem to be a problem for F# or Scala.

[james-uffindell-granta]

@HaloFour

Afterall, enum doesn't have any validation. You're free to cast 42 to System.DayOfWeek all day long and neither the language nor runtime care.

That's true, although I can't stand that behavior myself and wish that C# enums were more like Java ones 😄

I think even without validation, newtype wrappers would still be worth having, especially if the syntax for defining one is sufficiently low-ceremony. Most of the things I'd make wrappers for don't have a natural at-construction-time validation anyway so it probably wouldn't be too big of a loss.

I think custom equality is a bit harder to let go of; I expect a lot of string wrappers would want case-insensitive equality instead of normal equality and it would be nice to not have to manually remember that at every call site:

public alias CustomerId for string using StringComparer.InvariantCultureIgnoreCase;

var (c1, c2) = GetCustomerIds();
if (c1 == c2) { // does correct equality automatically

rather than:

public alias CustomerId for string; 

var (c1, c2) = GetCustomerIds();
// have to remember the right string comparison everywhere, what a palaver
if (string.Equals(c1.Value, c2.Value, StringComparison.InvariantCultureIgnoreCase)) {

That might be too much of a can of worms to open though, and I guess it isn't too much of a hardship to write the newtype the old-fashioned way if you want custom equality.

[theunrepentantgeek]

FWIW, when writing custom wrapper types around string, I avoid the problems caused by IEquatable<string> by instead offering a custom HasXYZ() predicate.

public struct CustomerId : IEquatable<CustomerId>
{
    private readonly string _id;
    public CustomerId(string id) { ... }
    public bool Equals(CustomerId other) => ...;
    public bool HasId(string id) => ...;
}

This gives a nice external API to consumers and allows me to centralise any case sensitivity decision internally, avoiding the subtle bugs that occur when uses are inconsistent.

[bondsbw]

@theunrepentantgeek Yep, I can imagine this for many cases. Goes back to @eyalsk's comment regarding customization (which is also similar to records).

[aka-nse]

The primitive types have special runtime supports for speed, so struct wrapper will cause performance degradation in some case.

The first case which I conjure is dictionary key.
They are depend on GetHashCode(), so its calling influences performance.

I tried the following benchmark.

using System;
using System.Collections.Generic;
using System.Linq;
using BenchmarkDotNet.Attributes;

namespace MyBenchmark
{
    public class StructHashCodeTest
    {

        public static IEnumerable<int> KeySource => Enumerable.Range(0, 0xfffff);

        public static Dictionary<int, int> IntKeyedDic =
            KeySource.ToDictionary(x => x, x => x);

        public static Dictionary<SimpleWrapper, int> SimpleWrapperKeyedDic =
            KeySource.ToDictionary(x => new SimpleWrapper(x), x => x);

        public static Dictionary<StandardWrapper, int> StandardWrapperKeyedDic =
            KeySource.ToDictionary(x => new StandardWrapper(x), x => x);

        [Benchmark]
        public int IntKeyed()
        {
            var retval = 0;
            foreach(var key in IntKeyedDic.Keys)
                retval += IntKeyedDic[key];
            return retval;
        }

        [Benchmark]
        public int SimpleIntWrapperKeyed()
        {
            var retval = 0;
            foreach(var key in SimpleWrapperKeyedDic.Keys)
                retval += SimpleWrapperKeyedDic[key];
            return retval;
        }

        [Benchmark]
        public int StandardIntWrapperKeyed()
        {
            var retval = 0;
            foreach(var key in StandardWrapperKeyedDic.Keys)
                retval += StandardWrapperKeyedDic[key];
            return retval;
        }

        [Benchmark]
        public int IntRecastedKeyed()
        {
            var retval = 0;
            foreach(var key in SimpleWrapperKeyedDic.Keys)
                retval += IntKeyedDic[key.Value];
            return retval;
        }
    }

    public readonly struct SimpleWrapper
    {
        public readonly int Value;

        public SimpleWrapper(int value) => Value = value;
    }

    public readonly struct StandardWrapper
    {
        public readonly int Value;

        public StandardWrapper(int value) => Value = value;

        public override bool Equals(object obj)
            => obj is StandardWrapper other && Value == other.Value;

        public override int GetHashCode() => Value.GetHashCode();

        public override string ToString() => Value.ToString();
    }
}

The following is the results.

BenchmarkDotNet=v0.10.14, OS=Windows 10.0.17134
Intel Core i7-6700K CPU 4.00GHz (Skylake), 1 CPU, 8 logical and 4 physical cores
Frequency=3914063 Hz, Resolution=255.4890 ns, Timer=TSC
.NET Core SDK=2.1.201
  [Host]     : .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT
  DefaultJob : .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT


                  Method |     Mean |     Error |    StdDev |
------------------------ |---------:|----------:|----------:|
                IntKeyed | 11.06 ms | 0.0226 ms | 0.0211 ms |
   SimpleIntWrapperKeyed | 75.23 ms | 0.3616 ms | 0.3383 ms |
 StandardIntWrapperKeyed | 16.34 ms | 0.0422 ms | 0.0374 ms |
        IntRecastedKeyed | 11.02 ms | 0.0255 ms | 0.0213 ms |

Let alone that struct implicit GetHashCode() is too slow, but explicitly overriding of GetHashCode() via Value has 50% performance cost.

Is this an acceptable cost?
I think that most coders will assume there is almost no extra cost in primitive type wrapper.

[HaloFour]

@glassgrass

The StandardIntWrapperKeyed benchmark would be appropriate for this proposal and I don't think that overhead is outrageous. Other languages that offer this feature like F# incur that or worse (in F# the wrapper is a class so you have an allocation as well).

[HaloFour]

@CyrusNajmabadi

Not a fan of the null-behavior not propagating into the wrapper. A null-string throws on things like .ToString. I would expect the wrapper to throw as well.

The more I think about this the more I think that it doesn't make sense for the wrapper to throw. The reason is that if the wrapper is a struct then consuming code, especially generic code, has no way to defend against the situation where the wrapped value is null. Comparing the wrapper to null will yield false, as the wrapper itself can't be null.

string GetString<T>(T value) => value?.ToString();

string s = null;
var id = (CustomerId)s;
GetString(id); // throws NullReferenceException

And given that the wrapper is a struct it's not possible for the language to prevent it from wrapping null as that is the default value.

How do people who write struct wrappers deal with this kind of situation today? Or do they manage it on a case-by-case basis and perhaps trust that they never let a wrapper get into this state?

[jnm2]

@HaloFour I either manage it so that zeroed fields represent a valid state, or I throw at each point as early as possible. (CustomerId)s would throw ArgumentNullException and instance members on default(CustomerId) would throw, like ImmutableArray.

[ymassad]

How does this feature compare to the following feature:

#259 (comment)

I am linking to a specific comment in #259 because in that comment, a special strict keyword is proposed so that different aliases of Int32 for example cannot be used interchangeably. The following is an excerpt from that comment:

using strict CustomerId = Int32;
using strict OrderId    = Int32;

In the referenced proposal, there would be no CustomerId type when the code is compiled into an assembly. However, maybe each property/parameter/field of this type can have a special attribute containing the name of the "type", e.g., "CustomerId". This way, consumers of the assembly would be able to see the CustomerId as a type.

[HaloFour]

@ymassad

The goals are the same but the implementation is certainly different. The type erasure of that proposal will inevitably lead to problems where that behavior cannot be enforced by anything. Downlevel compilers and other languages will continue to see that "CustomerId" as an int. You'd also have no ability to overload by those aliases since they're both just int. By going through a struct wrapper this proposal doesn't have any of those issues. Plus as a developer you can have more control over how the wrapper behaves as well as adding your own members.

[Alan-FGR]

Hi guys.

I'm researching the possibility of using a wrapped primitive for IDs in my ECS, so performance is very critical.

I'm doing some benchmarks here and while I could reproduce the results @glassgrass posted, that is easily 'fixable' by simply implementing IEquatable<StandardWrapper> (actual impl: public bool Equals(StandardWrapper other) => Value == other.Value;). I presume that's explainable by the type checking necessary in the object's Equals(object).

What's a bit strange though is that the hash of an int should be the int itself I think, so there's no point in also comparing by equality in this case, and that's an optimization I'd expect to happen under the hood for us.

I'm now looking for other cases where the wrapper might not be optimized out of the box to see if they're also 'fixable'. If you guys have any ideas of situations where there could be a difference in performance please let me know.

@HaloFour I pinged you on Gitter about this but deleted my wall of text by accident and couldn't find it in the browser memory :P

[v-natv]

My biggest pet peeve in dotnet code"

Dictionary<string, string> dict;

Okay... so... what is this doing?

[bboyle1234]

Here's a real-world example of such a thing:
Here, its constructor reformats the string before storing it So "demo-me" would end up the same as "DEMOME".
The wrapper class is indeed used to say "This may be a string, but it is not to be used as a string. I want to be compared a certain way. I want to be formatted a certain way, and so on."
I don't think there's a good "one solution fits all" to be found for the variety of real-world uses that should make its way into the language spec.
(The [Record] attribute is used to code-gen memberwise equality using https://github.com/amis92/RecordGenerator)

    [Serializable]
    [JsonConverter(typeof(Converter))]
    [Record(Features.OperatorEquals | Features.Equality)]
    public sealed partial class NadexUserName {

        public string Value { get; }

        public NadexUserName(string value) {
            if (string.IsNullOrWhiteSpace(value)) throw new ArgumentNullException(nameof(value));
            Value = value.ToUpperInvariant();
            if (Value.StartsWith("DEMO-"))
                Value = Value.Replace("DEMO-", "DEMO");
        }

        public override string ToString()
            => Value;

        public static NadexUserName FromString(string value)
            => string.IsNullOrWhiteSpace(value) ? null : new NadexUserName(value);

        public static explicit operator string(NadexUserName x)
            => x?.ToString();

        public static implicit operator NadexUserName(string x)
            => FromString(x);

        public class Converter : JsonConverter {
            public override bool CanConvert(Type objectType)
                => objectType == typeof(NadexUserName);

            public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer) {
                writer.WriteValue((value as NadexUserName)?.ToString());
            }

            public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer) {
                return FromString((string)reader.Value);
            }
        }
    }

[CodingMadness]

Hi, is there anything like this maybe implemented by now, for .NET 6+?

[HaloFour]

We do have record structs now:

public readonly record struct CustomerId(string Value);

[CodingMadness]

We do have record structs now:

public readonly record struct CustomerId(string Value);

this has nothing to do with creating a full "string-wrapper" who can do this:

CustomerID id = "Robert h. Johnson";

if (id.Contains("h.")
{ /*sucess! */ }

maybe also with internal attributes or extra auto-checks, which you can control with attribute-flags, where each string assignment is checked if its a fully Whitespace string or empty or null, if that is what one needs aswell. like this:

[AliasType(CompiletimeChecks.Exists = True)] //checks what I described right above.
public record struct CustomerID ()

[CodingMadness]

same goes ofc not only for string but for all primitive types.
//Defintion: //checks what I described right above, if the temperature is in the range of -273..40 Fahrenheit

[AliasType<Double>(MinValue = -273, MaxValue = 40)] 
public record struct Temperature () {   }

Temperature roomTemp = 100.0; //this should cause overflowexcp. at runtime! 
Temperature betterTmp = 39.3; //this is ok!
Console.Write(roomTemp == betterTmp );
Console.Write(roomTemp.ToString("%1"));
Console.Write(roomTemp.GetHashCode());
Console.Write(betterTmp + roomTemp2);

and so on...