www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The year is 2019

reply 12345swordy <alexanderheistermann gmail.com> writes:
Multi alias this is still not implemented. At this point of time 
I might as well  create a pr request that deprecate the alias 
this feature as it quite clearly that walter doesn't like it and 
hates implicit conversion for user types in general irregardless 
of design.


-Alex
Jul 25
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 26 July 2019 at 01:27:01 UTC, 12345swordy wrote:
 Multi alias this is still not implemented. At this point of 
 time I might as well  create a pr request that deprecate the 
 alias this feature as it quite clearly that walter doesn't like 
 it and hates implicit conversion for user types in general 
 irregardless of design.


 -Alex
I don't think that's the way to affect change, and your PR will just be closed, or worse, ignored. We can't deprecate `alias this` (at least in the near-to-medium term), but we may be able to provide alternatives. Andrei mentioned in a previous post that we've been too worried about making changes (https://forum.dlang.org/post/q7j3s0$15n7$1 digitalmars.com), and he advocated for changes that are "addition only". Of course, such changes still need to carry their weight, but it may be possible to add a feature to the language that is superior to `alias this` allowing it to gradually fall out of fashion, and in the long term, deprecated. If you want to move D forward in this regard, you have to strategize and make a good case for your changes. It's quite difficult, but also quite possible if you remain diplomatic and professional. Timing also plays a role. I believe Walter accepted some of my PRs for optional runtime features because he was also working on betterC at the time and those changes were congruent with his priorities at the time. I'm working on a proposal for `alias this`, but I need to make a strong case for it, and that can take a lot of time and effort. I know you had some ideas for making `opImplicitCast` more appealing. I'd be interested in hearing more about that, and if I think it will help my case, I'll incorporate them. Think about what it is that Walter cares about and consider how your proposal can provide him something he's been wanting. I think Walter is concerned about language and compiler complexity. There may be an opportunity there to improve the `alias this` implementation so the language and compiler will be less complex, and that may earn his support. It's true that once Walter has an idea in his head, it's extremely difficult to change his mind, but he's also not the only one that needs convincing. With a well-written DIP, and a strong case, Atila may get on board and provide the support needed to approve the feature. Mike
Jul 25
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 26 July 2019 at 01:53:18 UTC, Mike Franklin wrote:
 On Friday, 26 July 2019 at 01:27:01 UTC, 12345swordy wrote:
 [...]
I don't think that's the way to affect change, and your PR will just be closed, or worse, ignored. We can't deprecate `alias this` (at least in the near-to-medium term), but we may be able to provide alternatives. [...]
Do you have a draft already regarding this on github? I don't mind helping creating the dip. -Alex
Jul 26
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 26 July 2019 at 11:54:51 UTC, 12345swordy wrote:

 Do you have a draft already regarding this on github? I don't 
 mind helping creating the dip.
No, I'm sorry. I'm still collecting information and exploring ideas to build my case. You mentioned in on one of the recent PRs that you believe something like `opImplicitCast` could be implemented without some of the drawbacks present in C++'s implementation. I'm interested in your ideas. I need to make a strong case, so I'm exploring how to motivate my idea and I'm trying to discover any holes in it. There's also a DMD bug I'd like to resolve before submitting a DIP. In general, my idea is to create a more limited `alias this`-like feature that will eliminate some of the "weird sh**" that comes with `alias this` and only keep the good stuff. Whatever's left can be implemented with D's existing metaprogramming facilities. I believe it could be approved because it will significantly reduce the compiler's implementation and avoid a lot of bad interactions. I think that would be appealing to Walter and others. If you want to discuss it you're welcome to contact me on Slack, Discord, or IRC under the handle JinShil and I'll give you all the details of what I have in mind. Mike
Jul 26
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 26 July 2019 at 12:07:04 UTC, Mike Franklin wrote:
 On Friday, 26 July 2019 at 11:54:51 UTC, 12345swordy wrote:

 Do you have a draft already regarding this on github? I don't 
 mind helping creating the dip.
No, I'm sorry. I'm still collecting information and exploring ideas to build my case. You mentioned in on one of the recent PRs that you believe something like `opImplicitCast` could be implemented without some of the drawbacks present in C++'s implementation. I'm interested in your ideas. I need to make a strong case, so I'm exploring how to motivate my idea and I'm trying to discover any holes in it. There's also a DMD bug I'd like to resolve before submitting a DIP. In general, my idea is to create a more limited `alias this`-like feature that will eliminate some of the "weird sh**" that comes with `alias this` and only keep the good stuff. Whatever's left can be implemented with D's existing metaprogramming facilities. I believe it could be approved because it will significantly reduce the compiler's implementation and avoid a lot of bad interactions. I think that would be appealing to Walter and others. If you want to discuss it you're welcome to contact me on Slack, Discord, or IRC under the handle JinShil and I'll give you all the details of what I have in mind. Mike
I do not know the url for the discord for the dlang community...
Jul 26
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 26 July 2019 at 13:07:25 UTC, 12345swordy wrote:

 I do not know the url for the discord for the dlang community...
https://discordapp.com/invite/YFujqFZ
Jul 26
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 26 July 2019 at 13:17:53 UTC, Mike Franklin wrote:
 On Friday, 26 July 2019 at 13:07:25 UTC, 12345swordy wrote:

 I do not know the url for the discord for the dlang 
 community...
https://discordapp.com/invite/YFujqFZ
Joined.
Jul 26
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Thu, Jul 25, 2019 at 6:30 PM 12345swordy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Multi alias this is still not implemented. At this point of time
 I might as well  create a pr request that deprecate the alias
 this feature as it quite clearly that walter doesn't like it and
 hates implicit conversion for user types in general irregardless
 of design.


 -Alex
I don't personally like alias this except for very very specific use cases. I don't like that we use of for implicit conversion, and I hate that we use it for struct inheritance too. I want to be able to mark constructors as implicit or something (inverse to C++ `explicit`). That would be my preferred expression of implicit conversion.
Jul 26
parent reply XavierAP <n3minis-git yahoo.es> writes:
On Friday, 26 July 2019 at 21:37:33 UTC, Manu wrote:
 I don't personally like alias this except for very very 
 specific use
 cases. I don't like that we use of for implicit conversion, and 
 I hate
 that we use it for struct inheritance too.
Completely agree. I think struct inheritance (with no virtual dispatch) may be good for D. Has no one ever tried a DIP? Allowing inheritance or alias this to be multiple is a separate debate; I tend to think there's no sane use case. As is (but related) allowing structs to implement interfaces (as in C# or Go? And without violating their value semantics).
Jul 26
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 27 July 2019 at 04:15:38 UTC, XavierAP wrote:

 I think struct inheritance (with no virtual dispatch) may be 
 good for D. Has no one ever tried a DIP?
I'm formulating one, but I haven't gotten very far yet. Others have also mentioned interest. Walter is quite opposed to implicit casting (https://github.com/dlang/dmd/pull/10161) so I was thinking of a different strategy that would use keep the implicit casting feature of `alias this` but defer the forwarding to members to D's metaprogramming facilities.
 Allowing inheritance or alias this to be multiple is a separate 
 debate; I tend to think there's no sane use case. As is (but 
 related) allowing structs to implement interfaces (as in C# or 
 Go? And without violating their value semantics).
I think something like this should work: struct IStream { string read() { return ""; } } struct OStream { void write(string s) { }; } struct IOStream { IStream i; OStream o; // Generating the following functions can be automated with D's awesome // metaprogramming facilities string read() { return i.read(); } void write(string s) { o.write(s); } // But how do we implicitly convert from `IOStream` to `IStream` or // `OStream` without `alias this`, `opImplicitCast` or some other? alias i this; alias o this; // mulitple `alias this` currently not implemented, so // this doesn't work } extern string source(ref IStream i); extern void sink(ref OStream o); void main() { IOStream io; source(io); // Won't work without some kind of implicit casting sink(io); // Won't work without some kind of implicit casting } Mike
Jul 26
next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 27 July 2019 at 04:26:01 UTC, Mike Franklin wrote:
 struct IOStream
 {
     IStream i;
     OStream o;

     // Generating the following functions can be automated with 
 D's awesome
     // metaprogramming facilities
     string read() { return i.read(); }
     void write(string s) { o.write(s); }

     // But how do we implicitly convert from `IOStream` to 
 `IStream` or
     // `OStream` without `alias this`, `opImplicitCast` or some 
 other?
     alias i this;
     alias o this; // mulitple `alias this` currently not 
 implemented, so
                   // this doesn't work
 }
I was thinking of something simpler. And also new to the language, not that could or should be implemented by lowering (specially not lowering to alias this). Again leaving multiple aside: interface IPrintable { string toString(); } struct XY : IPrintable { disable this(); real x, y; string toString() { /*...*/ } // implicitly final always; virtual illegal in structs. } struct ParallelXY : XY { uint universe; void warp() { ++universe; } } Implement the same simple thing (including disable this() for every type) with current D (alias this) and see how much more typing and overhead.
Jul 26
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 27 July 2019 at 05:09:11 UTC, XavierAP wrote:

 I was thinking of something simpler. And also new to the 
 language, not that could or should be implemented by lowering 
 (specially not lowering to alias this).

 Again leaving multiple aside:

     interface IPrintable
     {
         string toString();
     }
I like the idea of using interfaces, but I'm not sure how to implement such a thing for structs. Is it just a compile-time contract? How does it work at runtime when we call a function like `void foo(IPrintable p);` with an instance of `XY` or `ParallelXY`?
     struct XY : IPrintable
     {
          disable this();
         real x, y;
         string toString() { /*...*/ }
         // implicitly final always; virtual illegal in structs.
     }
     struct ParallelXY : XY
     {
         uint universe;
         void warp() { ++universe; }
     }

 Implement the same simple thing (including  disable this() for 
 every type) with current D (alias this) and see how much more 
 typing and overhead.
Are you suggesting the body of `XY` simply be copied into `ParallelXY`? I think that can already be done with template mixins.
Jul 27
next sibling parent reply aliak <something something.com> writes:
On Saturday, 27 July 2019 at 09:38:20 UTC, Mike Franklin wrote:
 On Saturday, 27 July 2019 at 05:09:11 UTC, XavierAP wrote:

 I was thinking of something simpler. And also new to the 
 language, not that could or should be implemented by lowering 
 (specially not lowering to alias this).

 Again leaving multiple aside:

     interface IPrintable
     {
         string toString();
     }
I like the idea of using interfaces, but I'm not sure how to implement such a thing for structs. Is it just a compile-time contract? How does it work at runtime when we call a function like `void foo(IPrintable p);` with an instance of `XY` or `ParallelXY`?
You reminded me of the existence of this: https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
Jul 27
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 27/07/2019 10:46 PM, aliak wrote:
 On Saturday, 27 July 2019 at 09:38:20 UTC, Mike Franklin wrote:
 On Saturday, 27 July 2019 at 05:09:11 UTC, XavierAP wrote:

 I was thinking of something simpler. And also new to the language, 
 not that could or should be implemented by lowering (specially not 
 lowering to alias this).

 Again leaving multiple aside:

     interface IPrintable
     {
         string toString();
     }
I like the idea of using interfaces, but I'm not sure how to implement such a thing for structs.  Is it just a compile-time contract?  How does it work at runtime when we call a function like `void foo(IPrintable p);` with an instance of `XY` or `ParallelXY`?
You reminded me of the existence of this: https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
My signature DIP (one of the many versions of it). Current status: waiting on a dependency of named parameters before continuing.
Jul 27
prev sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 27 July 2019 at 09:38:20 UTC, Mike Franklin wrote:
 On Saturday, 27 July 2019 at 05:09:11 UTC, XavierAP wrote:

     interface IPrintable
     {
         string toString();
     }
I like the idea of using interfaces, but I'm not sure how to implement such a thing for structs. Is it just a compile-time contract? How does it work at runtime when we call a function like `void foo(IPrintable p);` with an instance of `XY` or `ParallelXY`?
Indeed the options and their consequences have to be studied. In principle I would constrain it, again no virtual dispatch whatsoever, and keep the value semantics. We can take a look at how C# already does it. I think Go has a similar feature. But imo it should imply polymorphism (e.g. in function parameter types) as you ask. And it's not only at runtime, or rather the border line between compile time and run time can be different for each program. Because unlike classes, structs are statically instantiated, the examples you ask may be ver well evaluating at ct, e.g. enum XY p = { 1, 2 }; enum s = p.toString(); But note also that interfaces in structs would be a separate feature/DIP from struct inheritance (from other structs, not interfaces). And given the extensive preference in the current D crowd (and in Phobos) for templates, there's no big use case for structs implementating interfaces, as there is however imo for inheritance.
 Are you suggesting the body of `XY` simply be copied into 
 `ParallelXY`?  I think that can already be done with template 
 mixins.
Indeed I know you can implement these simple features building on the more complex (and macro-ish), but it shouldn't be done this way, and that was my point. What I am suggesting is to implement new into the language the very simple inheritance that already exists for classes, or the same that C++ has for its RAII classes/structs. An inherited type includes (contains, memory-wise) the base type. The additional members defined in the derived type declaration are aligned after the inherited ones. That's why the derived type can also be used anywhere in place of the base one (polymorphism). Implementing this simple feature from template mixins does not guarantee this memory alignment. Plus imo it's wrong to build a brick out of houses. Here you have an example I wrote with (macro-ish) template mixins, while it would vave been much better with (private) inheritance: https://github.com/XavierAP/femd/blob/master/src/algebra/statics.d Amd here's another example where inheritance would have been better than composition: https://github.com/XavierAP/game-king/blob/master/source/sdl_help.d
Jul 27
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jul 26, 2019 at 9:30 PM Mike Franklin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 27 July 2019 at 04:15:38 UTC, XavierAP wrote:

 I think struct inheritance (with no virtual dispatch) may be
 good for D. Has no one ever tried a DIP?
I'm formulating one, but I haven't gotten very far yet. Others have also mentioned interest.
I would love to see this. Please do it.
 Walter is quite opposed to
 implicit casting (https://github.com/dlang/dmd/pull/10161) so I
 was thinking of a different strategy that would use keep the
 implicit casting feature of `alias this` but defer the forwarding
 to members to D's metaprogramming facilities.
The obvious counterpart to ` implicit` constructors is probably ` implicit` cast operators. Those aren't quite the same as "alias this stuff into 'this' scope", and at that very specific semantic, I think `alias this` is occasionally useful, but if you're just trying to emulate implicit construction or implicit casting, then I think there are better and more deliberate ways to do that, possibly with ` implicit`.
Jul 26
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 27 July 2019 at 05:09:18 UTC, Manu wrote:

 The obvious counterpart to ` implicit` constructors is probably
 ` implicit` cast operators.
 Those aren't quite the same as "alias this stuff into 'this' 
 scope",
 and at that very specific semantic, I think `alias this` is
 occasionally useful, but if you're just trying to emulate 
 implicit
 construction or implicit casting, then I think there are better 
 and
 more deliberate ways to do that, possibly with ` implicit`.
I would be perfectly happy with `opImiplicitCast` or some way to have implicit constructors. But Walter has already voiced his disapproval of that (See the comments in https://github.com/dlang/dmd/pull/10161 for the disappointment), so our choices are getting slim. I'm trying to find something he would be willing to approve. If you have any ideas, I'm all ears. I'm currently trying to collect ideas from others. Alex (12345swordy) gave me some good ideas yesterday, and I'm internalizing them. Here's what I'm thinking right now: Walter opposes implicit casts, but we already have `alias this`. `alias this` currently does 2 things: (1) It simulates an implicit cast (2) It forwards unresolved symbols to the aliased member. The problem with `alias this` is (2), and that causes a lot of resolution bugs and other "weird sh**". (1) is fine. (1) is all we need because we have enough metaprogramming facilities to implement (2) in the library. What I'm thinking is that we create a more limited `alias this` that only does (1). I'm thinking about syntax like this to distinguish it from the existing `alias this` feature. struct Base { void method1() { } void method2() { } } struct Derived { Base b; alias b; // `this` is implicit. That will distinguish it from // `alias b this` as the more limited `alias this` I // proposed above. It is an error to use both forms. mixin ForwardPublicMembers!(b); // The above mixin is a utility in the library that generates the // following // // void method2() // { // b.method2(); // } // // void method2() // { // b.method2(); // } } void foo(Base b) { } void main() { Derived d; foo(d); // Works because (1) -- the implicit casting behavior of // `alias this` is retained with `alias b` } This will keep the current `alias this` working as is, but allow us to introduce a new form. Why I think I might be able to make the case to Walter... 1. It's not the wild west of `opImplicitCast` or implicit constructors, which Walter already says he won't approve. 2. It's not much different from what we have today with `alias this`, so it's not a radical change, which I think Walter will appreciate. 3. If users migrate away from `alias b this;` and prefer `alias b;` then we may be able to deprecate the `alias b this` form along with all of its "weird sh**" resolution problems and bugs. I think Walter will appreciate that also. 4. In the long term, if `alias this` is deprecated we will be able to delete a huge mess of complexity from the compiler, and I think that will be appealing to Walter as well. 5. It doesn't break any existing code. `alias b this` will still work until we decide we don't want to support it anymore. This is an "addition-only" change. I may be wrong with my speculation here, but given the constraints Walter has voiced, it's the best I can think of. Either that or we have to try to convince Walter to embrace implicit casting, and you all know how that will likely end up. The only other saving grace may be Atila. Mike
Jul 27
next sibling parent Kagamin <spam here.lot> writes:
On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:
 (1) is all we need because we have enough metaprogramming 
 facilities to implement (2) in the library.  What I'm thinking 
 is that we create a more limited `alias this` that only does 
 (1).  I'm thinking about syntax like this to distinguish it 
 from the existing `alias this` feature.
Meh, that sounds bad. (1) doesn't achieve much without (2). And if you want your code to become a big ball of metaprogramming, you don't need alias this at all, you can replace it with DbI. You can replace most of the language with metaprogramming, and implement any type system there, it's basically lisp.
Jul 27
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:

 I would be perfectly happy with `opImiplicitCast` or some way 
 to have implicit constructors.  But Walter has already voiced 
 his disapproval of that (See the comments in 
 https://github.com/dlang/dmd/pull/10161 for the 
 disappointment), so our choices are getting slim.  I'm trying 
 to find something he would be willing to approve. If you have 
 any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
Jul 27
next sibling parent reply Exil <Exil gmall.com> writes:
On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:

 I would be perfectly happy with `opImiplicitCast` or some way 
 to have implicit constructors.  But Walter has already voiced 
 his disapproval of that (See the comments in 
 https://github.com/dlang/dmd/pull/10161 for the 
 disappointment), so our choices are getting slim.  I'm trying 
 to find something he would be willing to approve. If you have 
 any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
I don't agree. C++ strings are a good source of how it can be misused. I'm glad QString doesn't have implicit conversion with std::string. I remember reading a comment on a QString::fromStdString() call that was something along the lines of, "shitty QString doesn't support implicit conversion to std::string". I can only imagine how difficult it would be to track down all the implicit conversions to and from QString if it was an implicit conversion. And for whoever wrote that comment cause they didn't want to write a few extra characters. Ultimately it doesn't add functionality, it just reduces the amount of code you have to write by a small amount in some places and ultimately it makes your code less readable because of the hidden conversions. I don't think it's worth the price to pay.
Jul 27
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 July 2019 at 18:50:16 UTC, Exil wrote:
 On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:

 I would be perfectly happy with `opImiplicitCast` or some way 
 to have implicit constructors.  But Walter has already voiced 
 his disapproval of that (See the comments in 
 https://github.com/dlang/dmd/pull/10161 for the 
 disappointment), so our choices are getting slim.  I'm trying 
 to find something he would be willing to approve. If you have 
 any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
I don't agree. C++ strings are a good source of how it can be misused.
Any feature can be abused by a stubborn person. That is merely a case of bad coding practice rather then the feature itself.
Jul 27
parent reply Exil <Exil gmall.com> writes:
On Saturday, 27 July 2019 at 19:49:32 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 18:50:16 UTC, Exil wrote:
 On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin 
 wrote:

 I would be perfectly happy with `opImiplicitCast` or some 
 way to have implicit constructors.  But Walter has already 
 voiced his disapproval of that (See the comments in 
 https://github.com/dlang/dmd/pull/10161 for the 
 disappointment), so our choices are getting slim.  I'm 
 trying to find something he would be willing to approve. If 
 you have any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
I don't agree. C++ strings are a good source of how it can be misused.
Any feature can be abused by a stubborn person. That is merely a case of bad coding practice rather then the feature itself.
Not every feature can be abused. This one is far more easily abused than others, and people will use it for "convenience" as I have seen them complain about before. It makes it harder to read code, to maintain code. It is the feature itself. If you need to use it in such a small amount of code so that it isn't abused, then it isn't really something you need.
Jul 27
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 28 July 2019 at 00:45:54 UTC, Exil wrote:
 On Saturday, 27 July 2019 at 19:49:32 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 18:50:16 UTC, Exil wrote:
 On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin 
 wrote:

 I would be perfectly happy with `opImiplicitCast` or some 
 way to have implicit constructors.  But Walter has already 
 voiced his disapproval of that (See the comments in 
 https://github.com/dlang/dmd/pull/10161 for the 
 disappointment), so our choices are getting slim.  I'm 
 trying to find something he would be willing to approve. If 
 you have any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
I don't agree. C++ strings are a good source of how it can be misused.
Any feature can be abused by a stubborn person. That is merely a case of bad coding practice rather then the feature itself.
Not every feature can be abused.
I recall my programming instructor scolded me for abusing basic functions.
 This one is far more easily abused than others, and people will 
 use it for >"convenience" as I have seen them complain about 
 before.
Examples?
 It makes it harder to read code, to maintain code.
Opinion. Also you can make the same argument regarding the goto statement.
 It is the feature itself.
The goto feature exist. You want to argue for deprecation for that feature?
 If you need to use it in such a small amount of code so that it 
 isn't abused, then it isn't really something you need.
What language are you talking about here? Not every language implements implicit conversions the same way. For example C# rules for implicit conversions is much stricter then C++. Alex
Jul 27
next sibling parent Exil <Exil gmall.com> writes:
On Sunday, 28 July 2019 at 01:47:21 UTC, 12345swordy wrote:
 It is the feature itself.
The goto feature exist. You want to argue for deprecation for that feature?
It eases conversion from C/C++, so wouldn't be in the best interest to deprecate it. DMD probably wouldn't have been converted to D as easily, seeing how it abused goto.
Jul 30
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 28 July 2019 at 01:47:21 UTC, 12345swordy wrote:
  Also you can make the same argument regarding the goto 
 statement.
i <3 goto though i also wish we had implicit cast and implicit constructor more easily in d
Jul 31
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Sat, Jul 27, 2019 at 11:55 AM Exil via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:

 I would be perfectly happy with `opImiplicitCast` or some way
 to have implicit constructors.  But Walter has already voiced
 his disapproval of that (See the comments in
 https://github.com/dlang/dmd/pull/10161 for the
 disappointment), so our choices are getting slim.  I'm trying
 to find something he would be willing to approve. If you have
 any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
I don't agree. C++ strings are a good source of how it can be misused. I'm glad QString doesn't have implicit conversion with std::string. I remember reading a comment on a QString::fromStdString() call that was something along the lines of, "shitty QString doesn't support implicit conversion to std::string". I can only imagine how difficult it would be to track down all the implicit conversions to and from QString if it was an implicit conversion. And for whoever wrote that comment cause they didn't want to write a few extra characters. Ultimately it doesn't add functionality, it just reduces the amount of code you have to write by a small amount in some places and ultimately it makes your code less readable because of the hidden conversions. I don't think it's worth the price to pay.
You can only make the argument if you basically ignore meta-programming. This is a constant fight in D; where people seem to love extra special-case explicit junk in some cases, but the trouble is in any generic code, you then need to start doing: static if (is(T == SpecialCaseThing) { U x = special_case_conversion(thing); } else { U x = thing; // direct or implicit conversion } And that kind of thing is cancer to generic code, and having the power to specify some implicit conversions in code that are relevant to your program could reduce a whole lot of code like that. Generic code needs to be as short and brief as possible to remain easy to reason about, but then arguments like your one above cause exactly the kind of friction we should avoid. Now, you might make an argument about meta-programming at all; but meta-programming is D's single biggest undeniable advantage and success story over every other language, and frankly, if you're not behind meta-programming, you're in the wrong place. So I take that as guiding principle, and from there, I will always argue in favour of uniformity of expression, rather than requiring special-case manual shit on a case-by-case basis which is practically incompatible with meta-programming. I think implicit conversions are EXTREMELY enabling for a lot of cases of meta-programming in D, and I also feel much more comfortable with the idea that they are opt-in rather than opt-out as in C++. I think that's the right balance.
Jul 27
parent reply Exil <Exil gmall.com> writes:
On Saturday, 27 July 2019 at 22:36:23 UTC, Manu wrote:
 On Sat, Jul 27, 2019 at 11:55 AM Exil via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:
 On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin 
 wrote:

 I would be perfectly happy with `opImiplicitCast` or some 
 way to have implicit constructors.  But Walter has already 
 voiced his disapproval of that (See the comments in 
 https://github.com/dlang/dmd/pull/10161 for the 
 disappointment), so our choices are getting slim.  I'm 
 trying to find something he would be willing to approve. If 
 you have any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
I don't agree. C++ strings are a good source of how it can be misused. I'm glad QString doesn't have implicit conversion with std::string. I remember reading a comment on a QString::fromStdString() call that was something along the lines of, "shitty QString doesn't support implicit conversion to std::string". I can only imagine how difficult it would be to track down all the implicit conversions to and from QString if it was an implicit conversion. And for whoever wrote that comment cause they didn't want to write a few extra characters. Ultimately it doesn't add functionality, it just reduces the amount of code you have to write by a small amount in some places and ultimately it makes your code less readable because of the hidden conversions. I don't think it's worth the price to pay.
You can only make the argument if you basically ignore meta-programming. This is a constant fight in D; where people seem to love extra special-case explicit junk in some cases, but the trouble is in any generic code, you then need to start doing: static if (is(T == SpecialCaseThing) { U x = special_case_conversion(thing); } else { U x = thing; // direct or implicit conversion }
Not sure what you mean by this example. There already is implicit conversion when you declare variables. If "thing" can be converted to type U, then you don't need a special case. It just means the following: takes_type_u( U(thing) ); // no special case The only difference implicit conversion would make in this case is this: takes_type_u( thing ); // do we convert here or not? I get what you mean with generics though. It's why I don't use "const" why I don't use pointers and such. There are a lot of it already where you need special `static if`s to handle generic code. You can't even write generic code that works for nogc and GC. Yes it should be fixed but I don't see how it is easily fixable. Maybe it's just not the best example, I kind of know what you are trying to say but I can't think of a better example right now.
 And that kind of thing is cancer to generic code, and having 
 the power
 to specify some implicit conversions in code that are relevant 
 to your
 program could reduce a whole lot of code like that.
 Generic code needs to be as short and brief as possible to 
 remain easy
 to reason about, but then arguments like your one above cause 
 exactly
 the kind of friction we should avoid.

 Now, you might make an argument about meta-programming at all; 
 but
 meta-programming is D's single biggest undeniable advantage and
 success story over every other language, and frankly, if you're 
 not
 behind meta-programming, you're in the wrong place.
 So I take that as guiding principle, and from there, I will 
 always
 argue in favour of uniformity of expression, rather than 
 requiring
 special-case manual shit on a case-by-case basis which is 
 practically
 incompatible with meta-programming.

 I think implicit conversions are EXTREMELY enabling for a lot 
 of cases of meta-programming in D, and I also feel much more 
 comfortable with the idea that they are opt-in rather than 
 opt-out as in C++. I think that's the right balance.
I think it'd be even worse with meta programming. Now not only do you not know what type you may have, case it can be any type. You can also possibly convert it to any other type with implicit conversion. This would make it even more difficult to try to read and understand what is going on with implicit conversions. It could make it more powerful, and have the code be simpler. But overall it makes maintainability a pain, especially so since it makes the code look simpler, when in reality it is actually far more complicated.
Jul 27
parent reply Manu <turkeyman gmail.com> writes:
On Sat, Jul 27, 2019 at 5:45 PM Exil via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 27 July 2019 at 22:36:23 UTC, Manu wrote:
 I think implicit conversions are EXTREMELY enabling for a lot
 of cases of meta-programming in D, and I also feel much more
 comfortable with the idea that they are opt-in rather than
 opt-out as in C++. I think that's the right balance.
I think it'd be even worse with meta programming. Now not only do you not know what type you may have, case it can be any type. You can also possibly convert it to any other type with implicit conversion.
Not quite. I think you mean "you can also INTENTIONALLY convert it to SELECT other types with implicit conversion".
 This would make it even more difficult to try to read
 and understand what is going on with implicit conversions. It
 could make it more powerful, and have the code be simpler. But
 overall it makes maintainability a pain, especially so since it
 makes the code look simpler, when in reality it is actually far
 more complicated.
I find the bigger pain when I need to insert detection for specific things into meta-code, because they require a manual conversion step when the things is something that I'd like to convert implicitly.
Jul 27
parent Exil <Exil gmall.com> writes:
On Sunday, 28 July 2019 at 02:22:36 UTC, Manu wrote:
 On Sat, Jul 27, 2019 at 5:45 PM Exil via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 On Saturday, 27 July 2019 at 22:36:23 UTC, Manu wrote:
 I think implicit conversions are EXTREMELY enabling for a 
 lot of cases of meta-programming in D, and I also feel much 
 more comfortable with the idea that they are opt-in rather 
 than opt-out as in C++. I think that's the right balance.
I think it'd be even worse with meta programming. Now not only do you not know what type you may have, case it can be any type. You can also possibly convert it to any other type with implicit conversion.
Not quite. I think you mean "you can also INTENTIONALLY convert it to SELECT other types with implicit conversion".
The implicit conversion can be intentionally. But if you change a function signature, and it can implicitly convert to it. When you first wrote the code you didn't intend for it to be implicitly converted for that function. Code changes, and this sort of change won't give a compiler error when you make a change that wasn't intended to happen.
 This would make it even more difficult to try to read
 and understand what is going on with implicit conversions. It
 could make it more powerful, and have the code be simpler. But
 overall it makes maintainability a pain, especially so since it
 makes the code look simpler, when in reality it is actually far
 more complicated.
I find the bigger pain when I need to insert detection for specific things into meta-code, because they require a manual conversion step when the things is something that I'd like to convert implicitly.
Instead of inserting `static if` everywhere like you mention, if you have a function that does that instead then you don't need to do the checks at the calls sites. You just use the function that does the checks for you. Even still, why couldn't you just put a constructor for this case? Couldn't you just give U() the constructor to handle SpecialCaseThing? Then you wouldn't need the static if. This just isn't a very good example of what you intend, using `static if` here is your choice but there are alternatives already available to avoid it. static if (is(T == SpecialCaseThing) { U x = special_case_conversion(thing); } else { U x = thing; // direct or implicit conversion }
Jul 30
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Sat, Jul 27, 2019 at 9:15 AM 12345swordy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:

 I would be perfectly happy with `opImiplicitCast` or some way
 to have implicit constructors.  But Walter has already voiced
 his disapproval of that (See the comments in
 https://github.com/dlang/dmd/pull/10161 for the
 disappointment), so our choices are getting slim.  I'm trying
 to find something he would be willing to approve. If you have
 any ideas, I'm all ears.

 Mike
We shouldn't let Walter disapproval effect us. If we think it a really good idea then we should pursuit it. Walter thinks the opImplicitCast that we are proposing will be the same thing as C++. It isn't. C++ genius "idea" is to have implicit conversions opt-out rather then opt-in. -Alex
Right, the big difference is that implicit casting is opt-in. It would only be used when it makes good sense, and not by accident. I still think implicit applied to normal copy constructors and/or opCast is the best way though. That way the attribute can be extended in the future if it makes sense to expand, specifically on copy constructors where the function doesn't have a proper name.
Jul 27
prev sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:

 We shouldn't let Walter disapproval effect us. If we think it a 
 really good idea then we should pursuit it.

 Walter thinks the opImplicitCast that we are proposing will be 
 the same thing as C++. It isn't. C++ genius "idea" is to have 
 implicit conversions opt-out rather then opt-in.
I salute you if you want to write a DIP, and I'll support in whatever way I can. I might even be able to do the initial implementation, assuming I can figure it out. That will help motivate the DIP. Manu appears to prefer adding an ` implicit` attribute to the language for use on constructors and `opCast`. I think that will also work. I was leaning towards building on `alias this` simply because Walter has voiced opposition to implicit casting. If we can get implicit casting approved, that would actually be my preference. I think the DIP will have to build a very strong case including use cases and illustrating that it doesn't have the negative consequences of C++. Then it might have a chance. If the DIP fails, it will actually make any subsequent attempts just that much more difficult to justify, so it will need to be a damn good DIP. Mike
Jul 27
prev sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 27 July 2019 at 04:26:01 UTC, Mike Franklin wrote:
 On Saturday, 27 July 2019 at 04:15:38 UTC, XavierAP wrote:

 I think struct inheritance (with no virtual dispatch) may be 
 good for D. Has no one ever tried a DIP?
I'm formulating one, but I haven't gotten very far yet.
I think DIPs have much better chances if you separate them into single inheritance and eventually a second one to add multiplicity. Multiple inheritance is controversial enough on its own. If you merge it into any other DIP I am willing to bet anything the DIP will end up dead...
Jul 26
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 27 July 2019 at 06:58:58 UTC, XavierAP wrote:

 Multiple inheritance is controversial enough on its own. If you 
 merge it into any other DIP I am willing to bet anything the 
 DIP will end up dead...
I'm keeping that in mind. But we need to be more precise in our terminology. Yes, multiple inheritance has its problems, but what I'm proposing is NOT multiple inheritance. It is simply struct composition as it should be. We keep espousing "prefer composition over inheritance" but then the programming languages we design offer us precious little to actually do the right thing. I think D can be the first language to finally do composition right with this feature. Mike
Jul 27
parent XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 27 July 2019 at 08:32:07 UTC, Mike Franklin wrote:
 but what I'm proposing is NOT multiple inheritance.  It is 
 simply struct composition as it should be.
Ah well I was referring to simple plain old inheritance, so it'd be a separate topic/DIP. My question was whether a DIP about simple struct inheritance, and I interpreted Manu's past thread as requesting this (possibly among or together with other features); but I had misunderstood at least the former.
 We keep espousing "prefer composition over inheritance" but
I see the point in that statement, but I don't subscribe 100%. There's a pitfall in inheritance when you make too complex hierarchies, that are too inflexible to redesign. In this case if you had implemented the same from composition (e.g. entity-component-system architecture) it would be more flexible/better. But those cases don't mean imo that inheritance is anathema or never useful. Every feature can be abused (even templates, or metaprogramming ;)
 I think D can be the first language to finally do composition 
 right with this feature.
Sounds interesting.
Jul 27