Value objects with a single value

[AlwaysHC]

I'd like to have the possibility to declare simple value objects (class or record) that contains a single value and use that as default value.

public class Name {
   default string Value { get; init; }
   Name(string value) {
     Value=value;
   }
}

or

public record NickName(default string Value);

I could avoid a lot of errors with this feature.

Name name=new("Mirko");
Console.WriteLine(name); // Mirko
NickName nickName=new("AlwaysHC");
bool Equal = name == nickName; // Expected compilation error!!! :)

[HaloFour]

What does "default value" mean in this context? What problem is this trying to solve?

bool Equal = name == nickName; // Compilation error!!! :)

You mean it should be a compiler error, or that it is today and you want it to be something different?

[AlwaysHC]

Yes, that compilation error is what I expect

[AlwaysHC]

The idea is to have something similar to "User-Defined Types" in SQL Server

[333fred]

What would be different about this from a record struct with one field?

public readonly record struct Name(string Value);

[AlwaysHC]

At the moment then you always need to do:
NickName nickName=new("AlwaysHC");
Then:
Console.WritLine(nickName.Value);
instead of a simpler
Console.WritLine(nickName);

[333fred]

So override ToString and add an implicit conversion from string.

[AlwaysHC]

Really?
It could be feasible if we had a ToValue() instead of ToString() method in the Object class!

[FaustVX]

Will this be solved with Roles from #5496 ?

[FaustVX]

The meaning of role is to see type differently

role Name for string
{
  // your members specific for Name
}
role Nickname for string
{
  // your members specific for Nickname
}

Name name = "abc";
Nickname nickname = "abc";
name == nickname; // false, because Name and Nickname are different role, event is both are string.

I think the proposal works like that.

[AlwaysHC]

Or this: https://github.com/SteveDunn/Vogen

That proposal is stuck apparently

[333fred]

@FaustVX that last equality check would return true, not false.

[FaustVX]

@333fred I would expect the other way,
For example :
If I have a TempCelcius and a TempKelvin, both with the value of 5, there definitely not the same, and if for some reason, I want to compare the base value, I convert both to doublethen compare them.

[333fred]

@FaustVX that's not what the semantics of the roles proposal says will happen today. That comparison would return true.

[iam3yal]

I think the OP wants to implement an implicit conversion.

Name n = "Eyal"; // works.
string s = n; // works.

public record Name
{
    private readonly string _value;

    protected Name(string value)
        => _value = value;
        
    public static implicit operator string(Name name)
        => name._value;
        
    public static implicit operator Name(string value)
        => new (value);
}

[AlwaysHC]

Because I'd like to define different types for the different meanings of my data instead of using just the primitive types.

[iam3yal]

@AlwaysHC You can create a generic base class for this or you can use SG to achieve exactly that. you can use implicit conversion for whatever type you like... it's not only for primitives as long as you know how to construct the type I've just addressed your example above.

I'm doing something similar in my UI library so here is a simplified example, it looks like this:

public abstract record TypedString<T>
    where T : TypedString<T>, IValueDefaultable<T>
{
    private readonly string _value;

    protected TypedString(string value)
    {
        Contract.IsNotEmpty(value);

        _value = value;
    }

    public static implicit operator string(TypedString<T> type)
        => type._value;

    public override string ToString()
        => _value;
}


public sealed record InputType : TypedString<InputType>, IValueDefaultable<InputType>
{
    private InputType(string value) : base(value)
    {
    }

    public static InputType Default
        => Text;

    public static InputType CheckBox { get; } = new ("checkbox");
}
```</s>

[AlwaysHC]

What I want to achieve is to declare different types (from the standard one) that is not possible to implicitly convert to the standard one or their siblings.

[iam3yal]

@AlwaysHC Gotcha, you may want to add this info to the OP so people could understand your suggestion better.

[anranruye]

What I want to achieve is to declare different types (from the standard one) that is not possible to implicitly convert to the standard one or their siblings.

@AlwaysHC I don't understand. Do you mean that you want to avoid implicit conversion of BOTH directions? As I see, a Name is clearly a string but a string is not necessarily a Name. So the conversion from string to Name should be explicit, from Name to string should be implicit.

[anranruye]

You want to declare some wrapper types for primitive types and expect they act as their underlying primitive types. Is that right?

I don't think making wrapper types are ideal. It's clear that Names and NickNames are just strings and it' seems you don't intend to add more functions to these wrapper classes. If so, then no more types should be invovled.

Now we can declare alias for the exsisting types by:

using Name = System.String;
using NickName = System.String;

But the alias is only temporarily valid in the current file and the compiler doesn't prevent you from mixing different alias(all alias are considered as the same type).

There should be a new mechanism to make the alias reusable and force the alias can only replace another name by one direction(so logicly they are not the same type but subtypes and siblings at design/compile time; at runtime they are still the standard type).

The syntax may like:

using Name : System.String;
using PersonName : Name;
using CompanyName : Name;
...
void PrintPersonName(PersonName pName) => Console.Write(pName);
...
string personNameAsString = "Person Name";
Name personNameAsName = (Name)personNameAsString; // a string may not be a Name, should use an explicit conversion
PersonName personName = (PersonName)personNameAsName; // a Name may not be a PersonName
CompanyName companyName = (CompanyName)personName; // a PersonName is not a CompanyName

Name someName = personName; // ok, a PersonName must be a Name
string.IsNullOrEmpty(personName); // ok, a PersonName must be a string
companyName.First(); // IEnumerable<char>.First() extension method can be applied, this is not possible for a wrapper class

PrintPersonName((PersonName)companyName); // the method require a PersonName parameter, should use an explicit conversion

personNameAsName.GetType(); // System.String, Name is just an alias for String
personName.GetType(); // System.String
companyName.GetType(); // System.String

[iam3yal]

I don't think making wrapper types are ideal. It's clear that Names and NickNames are just strings and it' seems you don't intend to add more functions to these wrapper classes. If so, then no more types should be invovled.

A bit off-topic but generally speaking Name and Nickname are definitely not plain Strings for many reasons, they should be convertible to or interpreted as String but not vice-versa, meaning, just about any String isn't a Name also if both are simply aliases to Strings then why is it useful to have them? using alias should be used to resolve conflicts and make types easier to reach in some circumstances but not used in place of a full fledged type.

A Name might contain one of the following properties FirstName, MiddleName, LastName, FullName, Nickname, likewise the type Nickname might contain MinLength, MaxLength and both might not contain numbers, special characters or be empty it really depends on the domain/context.

With the introductions of roles into the language it's going to be pretty easy to create domain specific objects but then I don't think that comparing different roles with the same underlying type would result a compilation error as the OP expects but then it might be possible to write an analyzer for it.

[AlwaysHC]

That's why I'm proposing this "default" property or field.
Currently the only default method is "string ToString()".
When you create a "Value Object" then you always need to waste many chars in order to get the default value of that object... and you lose the real type too!
var Value = ValueObject.Value; // .Value is pointless.
var ValueObject2 = ValueObject; // This should create a copy of the v.o. and assign it to the new one.

Option 1:
class ValueObject {
private T _value;
public ValueObject(T value) {
_value=value;
}
public T ToValue() => _value; // ToValue should "replace" ToString as default method, if present
}
Option 2:
class ValueObject {
public default T Value {get; init;}; // This is the default property of the class, you don't need to specify that
public ValueObject(T value) {
Value=value;
}
}

[anranruye]

@eyalalonn Maybe you are right, but I think this is what the original post requests. I said

it' seems you don't intend to add more functions to these wrapper classes.

and this is the premise of the discussion. Rather than to create domain types, it seems that the author want to define custom primitive types which have unique names to distinguish from the basic ones.

The idea of aliases can have two variants:

1. The types can be REAL types which are derived from the primitive types, with no change:

public sealed class Name : System.String { }
public struct PersonId : System.Int32 { }

However, as we know, we can not define derived types from sealed classes and structs
2. The types are REAL types which copy the implementations of the basic types but have no inheritance relationship with the basic types :

public class Name from System.String;
public struct PersonId from System.Int32;

Compared with these two ways, I think probably it's better to use aliases which means:

1. No more types at runtime, since they are not necessary.
2. An analyzer will prevent the mixing of different aliases.

[AlwaysHC]

But the idea/possibility to add methods or other properties could be really nice!

[mattwar]

ToString() is a not a default method. It just seems that way because many runtime methods that otherwise have string parameters also have object parameter overloads that call ToString() for you.