Guid support

[xnf]

Is your feature request related to a problem? Please describe.
Hi. I would like to use Guid and quick search over the issues for a word "guid" showed at least two issues where people mention their own wrappers for guid.
I may be exaggerating but guid (v7 in particular) is a pretty common/popular these days. Don't take my word for it, i don't have the evidence.
While listening to to some of A.Zimarev presentations in Youtube, i may overheard that he is not interested in guid (again, with all due respect, i don't have evidence and i dont want to listen those hours of talk for something that perhaps was not even said).

Describe the solution you'd like
I know people here have their wrappers for guid->string->guid conversion. I have one too. If there is a popular demand and conceptual approve from the Eventuous leadership, i may contribute mine and then we talk.

Describe alternatives you've considered

1. having my own wrapper.
2. mapping back and froth as seen in this closed issue Using MapDiscoveredCommands with multiple aggregates results in error 'No handler found for command Object ' #264 _ => new CarId(Guid.NewGuid().ToString())

Additional context
I recently discovered Eventuous. Love it.

[linear]

EVE-190 Guid support

[alexeyzimarev]

I am a bit confused, where do you want to support GUID?

[bl-hashdex]

probably on Mongo projections that require by default a string Id.

[alexeyzimarev]

Yeah but Mongo projections work just fine 🤷‍♂️.

I kind of get a gist of it that maybe the thought is to use GUID instead of typed identity. Eventuous used to use strings for that purpose. The issue is that it weakens the type system. Or, maybe, the idea is to use GUID as the identity value, but it is limiting because a GUID can be converted to a string but not every string can be converted to a GUID. And, identity could be anything. Like, hashed email or ip address.

[xnf]

Hi. I don't usually comment on GH so forgive me if i am not clear.
@alexeyzimarev yes. I think you are correct about what my "thought" was.

Recap current situation as i see it:

The State expects TId to be extended from the string

public abstract record State<T, TId> : State<T> where T : State<T> where TId : Id

and constructor uses string without other overrides

public abstract record Id {
    protected Id(string value) {
       ...

My case

I use .NET System.Guid as primary id in my code. Which works nice because Eventuous stream ids "look like" GUID (plus bit more spices for JSON serialization).

But for this to work i created this monstrosity

public abstract record GuidId : Id
{
	protected GuidId(Guid value) : base(value.ToString())
	{
		GuidValue = value;
	}

	private Guid GuidValue { get; }

	public static implicit operator Guid(GuidId id)
	{
		return id?.GuidValue ?? throw new Exception("Id is null");
	}
}

public record MyRecordId : GuidId
{
	public MyRecordId() : base(Guid.CreateVersion7())
	{
	}

	public MyRecordId(Guid value) : base(value)
	{
	}
}

so i can use it for the state as public record MyRecordState : State< MyRecordState, MyRecordId>

My question

Given that GUIDs are popular and supported in .NET and Postgresql (both of which are supported my Eventuous), would you consider adding System.Guid as a support for state along with strings? As a generic, perhaps. I see your reasons for leaving them as just strings, since anything can be represented as a string.

Or can we (i can try, too) add a section in docs hinting how to use GUIDs.

[alexeyzimarev]

Just have a base record that uses Guid instead of string for the value is not a problem. However, it won't be used as UUID in Postgres as it requires schema changes.