You never asked for this but I’ve slowly started translating my posts to my native tongue.

https://sponsr.ru/glow/31355/Vnutri_sborshchika_musora_D

Hope it could be useful for my fellow citizens and if anything rereading my prose gives me new insights.

—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me

On Sunday, 21 April 2024 at 15:34:37 UTC, Dmitry Olshansky wrote:

Btw how many milestones from this old post were implemented?

On Sunday, 21 April 2024 at 16:41:07 UTC, Serg Gini wrote:

In the upstream, none as far as I know.
As to "Raven GC" I had in the works pretty much all of them, but the project got stagnated. I might be able to recover it though.

--
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me

On Sunday, 21 April 2024 at 15:34:37 UTC, Dmitry Olshansky wrote:

And here is the second one:

https://sponsr.ru/glow/54932/Samaya_bolshaya_oshibka_D/

One time I wanted inout in C#, that uses wrapper types for slices. How would you design it without inout?

Span<T> Shrink<T>(Span<T> s, int length)
{
	if (s.Length > length) return s.Slice(0, length);
	return s;
}

ReadOnlySpan<T> Shrink<T>(ReadOnlySpan<T> s, int length)
{
	if (s.Length > length) return s.Slice(0, length);
	return s;
}

void test(byte[] a)
{
	//var b = Shrink(a, 2); //can't infer type
	var b2 = Shrink<byte>(a, 2);
}

On Tuesday, 23 April 2024 at 13:38:41 UTC, Kagamin wrote:

Have Span be a subtype of ReadOnlySpan, either through interfaces and dynamic dispatch or through alias this and implicit conversion.

Span<T> Shrink<T>(Span<T> s, int length)
{
	if (s.Length > length) return s.Slice(0, length);
	return s;
}

ReadOnlySpan<T> Shrink<T>(ReadOnlySpan<T> s, int length)
{
	if (s.Length > length) return s.Slice(0, length);
	return s;
}

void test(byte[] a)
{
	//var b = Shrink(a, 2); //can't infer type
	var b2 = Shrink<byte>(a, 2);
}

Looks like the compiler here can't simultaneously do template inference, overload resolution and implicit conversion. I guess C++ somehow copes with that?

On Thursday, 25 April 2024 at 09:09:10 UTC, Kagamin wrote:

I’ve been doing a bit of Kotlin -> C# lately and found its type inference lacking. Things that are easily deduced by Kotlin compiler required direct parameters on the C# side. Mostly converting monadic parser code that uses a variation of Result monad. Lack of bottom type also hurts, plus had to introduce my own unit type.

—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me

Running on jvm, Kotlin presumably handles everything with GC allocated classes and single inheritance. C# can disambiguate such design, this compiles:

class A<T> { }
class B<T> : A<T> { }
class C<T> : B<T> { }

void test1<T>(A<T> a, int b) { }
void test1<T>(B<T> a, int b) { }
void test2(A<int> a, B<int> b, C<int> c)
{
	test1(a, 0);
	test1(b, 0);
	test1(c, 0);
}

But wrappers in C# use multiple inheritance. For some reason Memory doesn't implicitly convert to Span, but it's not in D tradition and it doesn't look like something prevents it, then type hierarchy would look like this:

class Memory<T> : ReadOnlyMemory<T>, Span<T>
class ReadOnlyMemory<T> : ReadOnlySpan<T>
class Span<T> : ReadOnlySpan<T>

i.e. the diamond pattern with multiple inheritance, I think this will be challenging to disambiguate, and it happens merely due to proliferation of wrapper types.