September 29, 2020
On 9/29/20 10:08 PM, Andrei Alexandrescu wrote:
> On 9/29/20 9:42 PM, Mike wrote:
>> On Wednesday, 30 September 2020 at 01:36:59 UTC, Mike wrote:
>>
>>> So, here are a couple of proposals off the top of my head.  I imagine someone more talented than I can think of a few more:
>>>
>>> 1.  Deprecate `alias this` for classes, and implement multiple `alias this` for structs.  That will give users the composition feature they need, and in addition, because structs cannot inherit, it removes the complexity Walter spoke of.
>>>
>>> 2.  Add `opImplicit`, implicit copy constructors, or something of that ilk.  Then users only need to forward members using D's metaprogramming facilities.  Both uses of `alias this` are covered, but no `alias this` is required.  `alias this` can then be deprecated entirely.
>>>
>>> 3.  Add struct inheritance like C++.
>>
>> 4. Somehow allow structs to implement interfaces.
> 
> I'd love it if interfaces could implement methods. (All MI related issues are related to state, not implementation of methods.)

BTW forgot to mention - this is from the category of removing limitations.
September 30, 2020
On Wednesday, 30 September 2020 at 02:08:17 UTC, Andrei Alexandrescu wrote:
> On 9/29/20 9:42 PM, Mike wrote:
>> On Wednesday, 30 September 2020 at 01:36:59 UTC, Mike wrote:
>> 
>>> So, here are a couple of proposals off the top of my head.  I imagine someone more talented than I can think of a few more:
>>>
>>> 1.  Deprecate `alias this` for classes, and implement multiple `alias this` for structs.  That will give users the composition feature they need, and in addition, because structs cannot inherit, it removes the complexity Walter spoke of.
>>>
>>> 2.  Add `opImplicit`, implicit copy constructors, or something of that ilk.  Then users only need to forward members using D's metaprogramming facilities.  Both uses of `alias this` are covered, but no `alias this` is required.  `alias this` can then be deprecated entirely.
>>>
>>> 3.  Add struct inheritance like C++.
>> 
>> 4. Somehow allow structs to implement interfaces.
>
> I'd love it if interfaces could implement methods. (All MI related issues are related to state, not implementation of methods.)

FWIW, C# 8 recently added such a feature.  They call it "Default Interface Members": https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/  However, the didn't finish the implementation and deferred this very important component:  https://github.com/dotnet/csharplang/issues/2337  I've used this feature quite a bit, but it's only mildly useful until #2337 is addressed.

That being said, I think that is somewhat tangential to the topic of this thread which I argue can be boiled down to "multiple alias this (or some other feature) is needed to do composition well with structs".
September 30, 2020
On 30/09/2020 2:42 PM, Mike wrote:
> 4. Somehow allow structs to implement interfaces.

Alternatively signatures.

A static interface that inherits from an implementation type like struct or class.

https://gist.github.com/rikkimax/826e1c4deb531e8dd993815bf914acea#signatures
September 29, 2020
On Wed, Sep 30, 2020 at 02:34:27AM +0000, Mike via Digitalmars-d wrote:
> On Wednesday, 30 September 2020 at 02:08:17 UTC, Andrei Alexandrescu wrote:
[...]
> > I'd love it if interfaces could implement methods. (All MI related issues are related to state, not implementation of methods.)
> 
> FWIW, C# 8 recently added such a feature.  They call it "Default
> Interface Members":
> https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/
> However, the didn't finish the implementation and deferred this very
> important component:  https://github.com/dotnet/csharplang/issues/2337
> I've used this feature quite a bit, but it's only mildly useful until
> #2337 is addressed.

Don't we already have this in D?

	interface I {
		void method1();	// overridable method
		final void method2() {} // default method
	}
	class C : I {
		void method1() {}
	}

Of course, currently method bodies in interfaces are only allowed when it's final.  This may or may not correspond with what C# does.


T

-- 
My program has no bugs! Only undocumented features...
September 30, 2020
On 9/30/20 12:12 AM, H. S. Teoh wrote:
> On Wed, Sep 30, 2020 at 02:34:27AM +0000, Mike via Digitalmars-d wrote:
>> On Wednesday, 30 September 2020 at 02:08:17 UTC, Andrei Alexandrescu wrote:
> [...]
>>> I'd love it if interfaces could implement methods. (All MI related
>>> issues are related to state, not implementation of methods.)
>>
>> FWIW, C# 8 recently added such a feature.  They call it "Default
>> Interface Members":
>> https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/
>> However, the didn't finish the implementation and deferred this very
>> important component:  https://github.com/dotnet/csharplang/issues/2337
>> I've used this feature quite a bit, but it's only mildly useful until
>> #2337 is addressed.
> 
> Don't we already have this in D?
> 
> 	interface I {
> 		void method1();	// overridable method
> 		final void method2() {} // default method
> 	}
> 	class C : I {
> 		void method1() {}
> 	}
> 
> Of course, currently method bodies in interfaces are only allowed when
> it's final.  This may or may not correspond with what C# does.

It looks like default method bodies are virtual and can be overridden.

I sort of remember at least having discussions about doing something like this, but I don't think it ever happened.

-Steve
September 29, 2020
On Wed, Sep 30, 2020 at 12:48:56AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 9/30/20 12:12 AM, H. S. Teoh wrote:
> > > On Wednesday, 30 September 2020 at 02:08:17 UTC, Andrei Alexandrescu wrote:
> > [...]
> > > > I'd love it if interfaces could implement methods. (All MI related issues are related to state, not implementation of methods.)
[...]
> > Don't we already have this in D?
> > 
> > 	interface I {
> > 		void method1();	// overridable method
> > 		final void method2() {} // default method
> > 	}
> > 	class C : I {
> > 		void method1() {}
> > 	}
> > 
> > Of course, currently method bodies in interfaces are only allowed when it's final.  This may or may not correspond with what C# does.
> 
> It looks like default method bodies are virtual and can be overridden.
> 
> I sort of remember at least having discussions about doing something like this, but I don't think it ever happened.
[...]

If we allow virtual non-abstract methods in interfaces, that would certainly be MI.  Though I'm guessing some people won't be happy until interfaces also carry state... :-P


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel
September 30, 2020
On Wednesday, 30 September 2020 at 01:36:59 UTC, Mike wrote:
> On Monday, 28 September 2020 at 19:55:10 UTC, Andrei Alexandrescu wrote:
>
> 1.  Deprecate `alias this` for classes, and implement multiple `alias this` for structs.  That will give users the composition feature they need, and in addition, because structs cannot inherit, it removes the complexity Walter spoke of.

This!

We've never used alias this for classes, I'm wondering if there's something like that in Phobos, or in other projects ...




September 30, 2020
On Wednesday, 30 September 2020 at 07:54:39 UTC, Paolo Invernizzi wrote:
> On Wednesday, 30 September 2020 at 01:36:59 UTC, Mike wrote:
>> On Monday, 28 September 2020 at 19:55:10 UTC, Andrei Alexandrescu wrote:
>>
>> 1.  Deprecate `alias this` for classes, and implement multiple `alias this` for structs.  That will give users the composition feature they need, and in addition, because structs cannot inherit, it removes the complexity Walter spoke of.
>
> This!
>
> We've never used alias this for classes, I'm wondering if there's something like that in Phobos, or in other projects ...

There's quite a few tests in Phobos for alias this on classes, but I wasn't able to find a single feature that uses this (and frankly, I'd be surprised if I did).

--
  Simen
September 30, 2020
On Wednesday, 30 September 2020 at 01:42:30 UTC, Mike wrote:
>
> 4. Somehow allow structs to implement interfaces.

Wouldn't that mean a vtable and therefore a POD violation?
September 30, 2020
On Wednesday, 30 September 2020 at 01:36:59 UTC, Mike wrote:
>
> 1.  Deprecate `alias this` for classes, and implement multiple `alias this` for structs.  That will give users the composition feature they need, and in addition, because structs cannot inherit, it removes the complexity Walter spoke of.
>
> 2.  Add `opImplicit`, implicit copy constructors, or something of that ilk.  Then users only need to forward members using D's metaprogramming facilities.  Both uses of `alias this` are covered, but no `alias this` is required.  `alias this` can then be deprecated entirely.
>
> 3.  Add struct inheritance like C++.

4. Remove "alias this" completely, use mixin templates instead. I originally misunderstood template mixins believing it was more or less just expansion into the scope. It turns out that there is a lot more going on under the hood, which makes the template mixin work like inheritance. This currently badly documented which makes people believe that template mixins are more limited.