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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 

Go? And without violating their value semantics).
Jul 26 2019
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 

 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 2019
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 2019
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 2019
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 2019
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 2019
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 


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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 

rules for implicit conversions is much stricter then C++.

Alex
Jul 27 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019