Re: Copy Constructor DIP and implementation

2018-09-24 Thread Jonathan M Davis via Digitalmars-d-announce
On Monday, September 24, 2018 9:33:19 PM MDT Manu via Digitalmars-d-announce 
wrote:
> On Mon, 24 Sep 2018 at 16:22, Jonathan M Davis via
>
> Digitalmars-d-announce  wrote:
> > On Monday, September 24, 2018 3:20:28 PM MDT Manu via
> > Digitalmars-d-announce>
> > wrote:
> > > copy-ctor is good, @implicit is also good... we want both. Even though
> > > copy-ctor is not strictly dependent on @implicit, allowing it will
> > > satisfy that there's not a breaking change, it it will also
> > > self-justify expansion of @implicit as intended without a separate and
> > > time-consuming fight, which is actually the true value of this DIP!
> >
> > @implicit on copy constructors is outright bad. It would just be a
> > source of bugs. Every time that someone forgets to use it (which plenty
> > of programmers will forget, just like they forget to use @safe, pure,
> > nothrow, etc.), they're going to have a bug in their program.
>
> perhaps a rule where declaring a copy-ctor WITHOUT @explicit emits a
> compile error...?

That would pretty much defeat the whole purpose of why @implicit was added
to the DIP in the first place. It's just that it would turn the feared
silent code breakage into a compiler error. So, I suppose that it would be
an improvement, but it's the sort of thing that would have to go behind a
transitional compiler switch, and as soon as we do that, why have @implicit
on copy constructors at all? It makes far more sense to use a transitional
compiler switch to simply sort out the problem with the potential (but
highly unlikely) silent breakage and not do anything with @implicit with
copy constructors whatsoever. It avoids having to put a useless attribute on
copy constructors forever, and it avoids any potential bugs.

Then we can have a separate DIP that deals with @implicit and non-copy
constructors for implicit construction. And maybe we do ultimately end up
with @implicit on constructors in D. But if @implicit ends up on copy
constructors, at best, it's going to be a language wort, since it adds zero
value there, but as the DIP currently stands, it's going to be a source of
bugs.

- Jonathan M Davis





Re: Copy Constructor DIP and implementation

2018-09-24 Thread Manu via Digitalmars-d-announce
On Mon, 24 Sep 2018 at 16:22, Jonathan M Davis via
Digitalmars-d-announce  wrote:
>
> On Monday, September 24, 2018 3:20:28 PM MDT Manu via Digitalmars-d-announce
> wrote:
> > copy-ctor is good, @implicit is also good... we want both. Even though
> > copy-ctor is not strictly dependent on @implicit, allowing it will
> > satisfy that there's not a breaking change, it it will also
> > self-justify expansion of @implicit as intended without a separate and
> > time-consuming fight, which is actually the true value of this DIP!
>
> @implicit on copy constructors is outright bad. It would just be a source of
> bugs. Every time that someone forgets to use it (which plenty of programmers
> will forget, just like they forget to use @safe, pure, nothrow, etc.),
> they're going to have a bug in their program.

perhaps a rule where declaring a copy-ctor WITHOUT @explicit emits a
compile error...?


Re: Copy Constructor DIP and implementation

2018-09-24 Thread Jonathan M Davis via Digitalmars-d-announce
On Monday, September 24, 2018 7:59:36 PM MDT Nicholas Wilson via 
Digitalmars-d-announce wrote:
> On Monday, 24 September 2018 at 23:22:13 UTC, Jonathan M Davis
>
> wrote:
> > @implicit on copy constructors is outright bad. It would just
> > be a source of bugs. Every time that someone forgets to use it
> > (which plenty of programmers will forget, just like they forget
> > to use @safe, pure, nothrow, etc.), they're going to have a bug
> > in their program. However, unlike, with attributes like @safe
> > or pure, they're not going to get a compiler error in their
> > program; they're going to get a logic error. They may or may
> > not find that bug quickly, but the compiler isn't going to
> > point it out to them.
>
> I think this is the most important reason. In C++, where
> everything is implicit by default (which is bad) and (I think)
> you are encouraged to use explicit where possible, you should
> never use it for the copy constructor because the compiler always
> calls it implicitly for you and is the whole point of having:
>
> Foo a; Foo b = a;
>
> do something useful. Putting explicit on the copy ctor means that
> no longer works, one can then only use it with
>
> Foo a; Foo b(a);
>
> Having `Foo a; Foo b = a;` do something completely different by
> the addition or removal of one attribute is a serious problem
> just waiting to happen.

The key thing with explicit in C++ is to avoid issues with implicit
conversions between types. You can get weird junk like where

int foo(string s);

foo(42);

compiles, because you have a type A with an implicit constructor which takes
int, and an implicit conversion to string. Even though A isn't explicitly
used here anywhere, because it's available, and no more than three
conversions are required to go from int to string when using A, the compiler
will use A to from int to string. That probably isn't what the programmer
wanted, but the compiler will happily do it.

Because of this, it's best practice in C++ to put explicit on any
constructors which take other types where you don't explicitly want the
implicit conversion in order to try to avoid this conversion mess. You then
only leave explicit off of constructors where you want the implicit
conversion or constructors where it's unnecessary (e.g. default constructors
or copy constructors). D avoids this mess by simply not having any kind of
implicit construction. It just has implicit conversion via alias this. It
may or may not be worth adding implicit construction via something like
@implicit, but it would at least then only be on constructors which were
explicitly marked with @implicit, whereas with C++, you have to use explicit
to turn off the behavior. So, in C++, it's a total mess by default, whereas
in D, we'd only have it where the programmer asked for it. And presumably,
any DIP that added it wouldn't have the compiler do more than one conversion
at a time, whereas as I understand it, C++ allows the compiler to do up to
three conversions in order to make a piece of code work. But ultimately,
such details will have to be decided with such a DIP.

Either way, none of this has anything to do with copy constructors. It makes
no sense to have copy constructors that require that you call them
explicitly. And while it would be bad enough if the DIP required that you
mark copy constructors with @implicit for them to work as copy constructors
and then didn't have implicit copying without @implicit, that's not what it
does. Instead, what it does when you forget @implicit is revert to the
default copy semantics, meaning that you have a copy constructor that needs
to be called explicitly, but you didn't realize that it needed to be called
explicitly, and you're blindly using the default copy semantics rather than
the copy constructor. So, the semantics that the DIP describes are just
plain a recipe for bugs. But since the PR has been updated to remove
@implicit, maybe the DIP will be updated to remove it as well, and the whole
@implicit discussion can be left to a future DIP on implicit construction
and left out of copy construction entirely.

- Jonathan M Davis





Re: Copy Constructor DIP and implementation

2018-09-24 Thread Nicholas Wilson via Digitalmars-d-announce
On Monday, 24 September 2018 at 23:22:13 UTC, Jonathan M Davis 
wrote:
@implicit on copy constructors is outright bad. It would just 
be a source of bugs. Every time that someone forgets to use it 
(which plenty of programmers will forget, just like they forget 
to use @safe, pure, nothrow, etc.), they're going to have a bug 
in their program. However, unlike, with attributes like @safe 
or pure, they're not going to get a compiler error in their 
program; they're going to get a logic error. They may or may 
not find that bug quickly, but the compiler isn't going to 
point it out to them.


I think this is the most important reason. In C++, where 
everything is implicit by default (which is bad) and (I think) 
you are encouraged to use explicit where possible, you should 
never use it for the copy constructor because the compiler always 
calls it implicitly for you and is the whole point of having:


Foo a; Foo b = a;

do something useful. Putting explicit on the copy ctor means that 
no longer works, one can then only use it with


Foo a; Foo b(a);

Having `Foo a; Foo b = a;` do something completely different by 
the addition or removal of one attribute is a serious problem 
just waiting to happen.





Re: Copy Constructor DIP and implementation

2018-09-24 Thread Jonathan M Davis via Digitalmars-d-announce
On Monday, September 24, 2018 3:20:28 PM MDT Manu via Digitalmars-d-announce 
wrote:
> copy-ctor is good, @implicit is also good... we want both. Even though
> copy-ctor is not strictly dependent on @implicit, allowing it will
> satisfy that there's not a breaking change, it it will also
> self-justify expansion of @implicit as intended without a separate and
> time-consuming fight, which is actually the true value of this DIP!

@implicit on copy constructors is outright bad. It would just be a source of
bugs. Every time that someone forgets to use it (which plenty of programmers
will forget, just like they forget to use @safe, pure, nothrow, etc.),
they're going to have a bug in their program. However, unlike, with
attributes like @safe or pure, they're not going to get a compiler error in
their program; they're going to get a logic error. They may or may not find
that bug quickly, but the compiler isn't going to point it out to them. And
if @implicit weren't a thing, then the problem wouldn't even exist.
@implicit is trying to get around breaking an extremely unlikely piece of
code which would be far better fixed by using a transitional compiler flag
and which adds _no_ value for copy constructors in the long run.

Even if we do later add @implicit to the language for regular constructors,
it has no business on copy constructors. And its value on other constructors
needs to be evaluated and examined on its own separately from the issue of
copy constructors. We should not be letting @implicit be put onto copy
constructors just to get it into the language. If it's such a valuable
feature on regular constructors, it should be able to get in on a separate
DIP specifically for that purpose without piggybacking in on the copy
constructor DIP - especially when it's clearly going to be a source of bugs
if it's required to be on copy constructors. And it just needlessly adds to
the attribute soup. At least if it were added for regular constructors, it
would be adding value. For copy constructors, it's just adding annoyance and
the risk of bugs.

- Jonathan M Davis





Re: Copy Constructor DIP and implementation

2018-09-24 Thread Jonathan M Davis via Digitalmars-d-announce
On Monday, September 24, 2018 10:44:01 AM MDT Meta via Digitalmars-d-
announce wrote:
> On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis
>
> wrote:
> > @implicit is just there because of the fear of breaking a
> > theoretical piece of code that's going to be extremely rare if
> > it exists at all and in most cases would continue to work just
> > fine even if it did exist.
> >
> > - Jonathan M Davis
>
> I somewhat agree with this argument, but overall I hate this
> attitude of "we should just make the change because it *probably*
> won't break any code", and then bonus points for "code that does
> this is wrong anyway so we shouldn't care if we break it". I've
> already been burned by that a couple times using D, and I imagine
> heavy corporate users with large code bases have many more
> problems with this.

In this particular case, a transitional compiler flag like we've done with
other DIPs makes _far_ more sense than forcing everyone to use an attribute
forever - especially when forgetting to use the attribute is going to be a
further source of bugs, one which would _easily_ outweigh any code breakage
caused by not having the attribute. But having a transitional compiler flag
would give us a way to deal with the potential code breakage if it exists.

- Jonathan M Davis





Re: Copy Constructor DIP and implementation

2018-09-24 Thread Manu via Digitalmars-d-announce
On Mon, 24 Sep 2018 at 12:40, 12345swordy via Digitalmars-d-announce
 wrote:
>
> On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
> > On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via
> > Digitalmars-d-announce 
> > wrote:
> >>
> >> On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson
> >> wrote:
> >> > It appears that @implicit has been removed from the
> >> > implementation [1], but not yet from the DIP.
> >> >
> >> > https://github.com/dlang/dmd/commit/cdd8100
> >>
> >> Good, It's not needed.
> >
> > @implicit is desperately needed (just not for copy
> > constructors!). Do you have confidence that an @implicit
> > proposal will happen if you all insist that it's removed here?
> > This is a great driving motivator to support @implicit's
> > introduction.
>
> If we are going to introduce the keyword/attribute implicit then
> it needs its own DIP. As of now, this DIP have a very weak
> justification for it.

I certainly agree; I'm fairly sure I produced the very first critical
comment on this issue when it first landed, which went like "@implicit
is a dependency and needs a dependent dip", which Andrei brushed off.
I still believe it's a separate feature, and it's a dependency for
this particular DIP, so that should come first... but here's the
thing; that's just not how dlang works around here.
We like the idea that there's process and structure, but there's not,
and you just need to be practical about maneuvering towards the goals
you want in the ways that manifest.

In this case, having @implicit is a very real and desirable goal, it's
been a sore hole in the language since ever... so anything that moves
it towards reality is preferable to nothing.
While I felt strongly about my conviction initially (that there should
be a dependent DIP), I realised that a much more useful and practical
position was to allow this dip to introduce @implicit implicitly
(heh)... that's a much better reality than waiting an addition year or
2 (if ever!) for the thing otherwise.

I encourage people to consider this holistically and consider the
practicality of allowing it, even thought it's not a strictly
principled in terms of process ;)

copy-ctor is good, @implicit is also good... we want both. Even though
copy-ctor is not strictly dependent on @implicit, allowing it will
satisfy that there's not a breaking change, it it will also
self-justify expansion of @implicit as intended without a separate and
time-consuming fight, which is actually the true value of this DIP!


Re: Copy Constructor DIP and implementation

2018-09-24 Thread 12345swordy via Digitalmars-d-announce

On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via 
Digitalmars-d-announce  
wrote:


On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson 
wrote:
> It appears that @implicit has been removed from the 
> implementation [1], but not yet from the DIP.

>
> https://github.com/dlang/dmd/commit/cdd8100

Good, It's not needed.


@implicit is desperately needed (just not for copy 
constructors!). Do you have confidence that an @implicit 
proposal will happen if you all insist that it's removed here? 
This is a great driving motivator to support @implicit's 
introduction.


If we are going to introduce the keyword/attribute implicit then 
it needs its own DIP. As of now, this DIP have a very weak 
justification for it.


-Alex


Re: Copy Constructor DIP and implementation

2018-09-24 Thread Manu via Digitalmars-d-announce
On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via
Digitalmars-d-announce  wrote:
>
> On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson
> wrote:
> > It appears that @implicit has been removed from the
> > implementation [1], but not yet from the DIP.
> >
> > https://github.com/dlang/dmd/commit/cdd8100
>
> Good, It's not needed.

@implicit is desperately needed (just not for copy constructors!).
Do you have confidence that an @implicit proposal will happen if you
all insist that it's removed here? This is a great driving motivator
to support @implicit's introduction.


Re: Copy Constructor DIP and implementation

2018-09-24 Thread Meta via Digitalmars-d-announce
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis 
wrote:
@implicit is just there because of the fear of breaking a 
theoretical piece of code that's going to be extremely rare if 
it exists at all and in most cases would continue to work just 
fine even if it did exist.


- Jonathan M Davis


I somewhat agree with this argument, but overall I hate this 
attitude of "we should just make the change because it *probably* 
won't break any code", and then bonus points for "code that does 
this is wrong anyway so we shouldn't care if we break it". I've 
already been burned by that a couple times using D, and I imagine 
heavy corporate users with large code bases have many more 
problems with this.


Re: Copy Constructor DIP and implementation

2018-09-24 Thread Gary Willoughby via Digitalmars-d-announce
On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson 
wrote:
It appears that @implicit has been removed from the 
implementation [1], but not yet from the DIP.


https://github.com/dlang/dmd/commit/cdd8100


Good, It's not needed.


Re: Webassembly TodoMVC

2018-09-24 Thread Sebastiaan Koppe via Digitalmars-d-announce

On Sunday, 23 September 2018 at 18:36:11 UTC, Joakim wrote:
Vladimir mentioned that there's a Musl port to wasm, have you 
tried it?


https://github.com/jfbastien/musl

Druntime and ldc support Musl.


Thanks for the link, I will have a look at it!