digitalmars.D - Mixin overload sets
- BLM768 (51/51) Aug 14 2013 The current behavior of placing identically-named functions from
The current behavior of placing identically-named functions from separate mixins into separate overload sets works well most of the time, but there are cases when the functions should be in the same overload set, and the aliasing required to allow overloading can quickly get tedious and clutter the namespace where the mixins are used, especially if the mixins define multiple functions. mixin template someMixin(Args ...) { void abc(Args) {}; void def(int, Args); } struct HasMixins { mixin someMixin!int mixinInt; alias mixinInt.abc abc; alias mixinInt.def def; mixin someMixin!float mixinFloat; alias mixinFloat.abc abc; alias mixinFloat.def def; //and so on... } It would be nice if we had a more concise way to pull all of the duplicate functions into a single overload set. I can think of two ways to handle this: 1. Introduce a new syntax. struct HasMixins { //One possible syntax: alias mixin someMixin!int this; alias mixin someMixin!float this; //etc. } HasMixins hm; hm.abc(3f); //Would call HasMixins.abc(float) 2. Automatically place functions that come from different instances of the same mixin template into the same namespace. struct HasMixins { mixin someMixin!int; mixin someMixin!float; } HasMixins hm; hm.abc(3f); //Would call HasMixins.abc(float) mixin template someOtherMixin { void abc() {}; } struct HasOtherMixins { mixin someMixin!int; mixin someMixin!float; mixin someOtherMixin; } HasOtherMixins hm2; hm2.abc(3f); //error Thoughts?
Aug 14 2013
On Wednesday, 14 August 2013 at 17:35:28 UTC, BLM768 wrote:The current behavior of placing identically-named functions from separate mixins into separate overload sets works well most of the time, but there are cases when the functions should be in the same overload set, and the aliasing required to allow overloading can quickly get tedious and clutter the namespace where the mixins are used, especially if the mixins define multiple functions. mixin template someMixin(Args ...) { void abc(Args) {}; void def(int, Args); } struct HasMixins { mixin someMixin!int mixinInt; alias mixinInt.abc abc; alias mixinInt.def def; mixin someMixin!float mixinFloat; alias mixinFloat.abc abc; alias mixinFloat.def def; //and so on... } It would be nice if we had a more concise way to pull all of the duplicate functions into a single overload set. I can think of two ways to handle this: 1. Introduce a new syntax. struct HasMixins { //One possible syntax: alias mixin someMixin!int this; alias mixin someMixin!float this; //etc. } HasMixins hm; hm.abc(3f); //Would call HasMixins.abc(float) 2. Automatically place functions that come from different instances of the same mixin template into the same namespace. struct HasMixins { mixin someMixin!int; mixin someMixin!float; } HasMixins hm; hm.abc(3f); //Would call HasMixins.abc(float) mixin template someOtherMixin { void abc() {}; } struct HasOtherMixins { mixin someMixin!int; mixin someMixin!float; mixin someOtherMixin; } HasOtherMixins hm2; hm2.abc(3f); //error Thoughts?You can put those functions into HasOtherMixins by using alias. struct HasOtherMixins { ... alias someMixin!int.abc abc; alias someMixin!float.abc abc; alias someOtherMixin abc; }
Aug 16 2013
On Friday, 16 August 2013 at 07:48:52 UTC, QAston wrote:On Wednesday, 14 August 2013 at 17:35:28 UTC, BLM768 wrote:Ah, I just saw you did that in the beginning of the post. I blame missing that to writing this early in the morning :)The current behavior of placing identically-named functions from separate mixins into separate overload sets works well most of the time, but there are cases when the functions should be in the same overload set, and the aliasing required to allow overloading can quickly get tedious and clutter the namespace where the mixins are used, especially if the mixins define multiple functions. mixin template someMixin(Args ...) { void abc(Args) {}; void def(int, Args); } struct HasMixins { mixin someMixin!int mixinInt; alias mixinInt.abc abc; alias mixinInt.def def; mixin someMixin!float mixinFloat; alias mixinFloat.abc abc; alias mixinFloat.def def; //and so on... } It would be nice if we had a more concise way to pull all of the duplicate functions into a single overload set. I can think of two ways to handle this: 1. Introduce a new syntax. struct HasMixins { //One possible syntax: alias mixin someMixin!int this; alias mixin someMixin!float this; //etc. } HasMixins hm; hm.abc(3f); //Would call HasMixins.abc(float) 2. Automatically place functions that come from different instances of the same mixin template into the same namespace. struct HasMixins { mixin someMixin!int; mixin someMixin!float; } HasMixins hm; hm.abc(3f); //Would call HasMixins.abc(float) mixin template someOtherMixin { void abc() {}; } struct HasOtherMixins { mixin someMixin!int; mixin someMixin!float; mixin someOtherMixin; } HasOtherMixins hm2; hm2.abc(3f); //error Thoughts?You can put those functions into HasOtherMixins by using alias. struct HasOtherMixins { ... alias someMixin!int.abc abc; alias someMixin!float.abc abc; alias someOtherMixin abc; }
Aug 16 2013
On Friday, 16 August 2013 at 07:48:52 UTC, QAston wrote:You can put those functions into HasOtherMixins by using alias. struct HasOtherMixins { ... alias someMixin!int.abc abc; alias someMixin!float.abc abc; alias someOtherMixin abc; }Actually, that syntax only works for regular templates, not mixins. Trying it with a mixin template gives an error. It's also not very useful when mixing in several methods from the same template. However, the first solution I suggested could be expanded to support that type of syntax: struct HasMixins { alias mixin someMixin!int.abc abc; //etc. } I'm starting to lean toward the first option as the more "correct" solution because it's more flexible and follows the principle of least surprise. If it's decided that this would be an acceptable addition to the language, I could try to cobble a pull request together. I don't have any experience with the DMD codebase, but it might be a good introductory project for me...
Aug 16 2013