On 12/22/2018 2:47 AM, Atila Neves wrote:
>> D isn't any more suitable for in-browser code than C++ is. A native language with raw pointers would not be a good choice for an embeddable scripting language.
> 
> And yet, people have been compiling C++ and running it in the browser for a while.

I didn't know that. But one can support "raw" pointers in a sandbox via emulation. But then one loses the benefits of raw pointers. It doesn't change my opinion that C++ is unsuitable for in-browser work.

As I recall, there is "managed C++" which was Microsoft getting C++ to work with CLI, but they did it by extensively modifying the language.

https://en.wikipedia.org/wiki/C%2B%2B/CLI

On Wednesday, 26 December 2018 at 22:33:18 UTC, Walter Bright wrote:
> On 12/22/2018 2:47 AM, Atila Neves wrote:
>>> D isn't any more suitable for in-browser code than C++ is. A native language with raw pointers would not be a good choice for an embeddable scripting language.
>> 
>> And yet, people have been compiling C++ and running it in the browser for a while.
>
> I didn't know that. But one can support "raw" pointers in a sandbox via emulation. But then one loses the benefits of raw pointers. It doesn't change my opinion that C++ is unsuitable for in-browser work.
>
> As I recall, there is "managed C++" which was Microsoft getting C++ to work with CLI, but they did it by extensively modifying the language.
>
> https://en.wikipedia.org/wiki/C%2B%2B/CLI

C++/CLI is dead, long live C++/CX

https://en.wikipedia.org/wiki/C%2B%2B/CX

On 12/25/2018 4:50 AM, Rubn wrote:
> What makes you think C++ celebrates it?

The debates about it in the 1980s.

On Thursday, 27 December 2018 at 01:53:32 UTC, Walter Bright wrote:
> On 12/25/2018 4:50 AM, Rubn wrote:
>> What makes you think C++ celebrates it?
>
> The debates about it in the 1980s.

So you are basing your opinion on debates from 40 years ago? What debates was D having in the 1980s?

On Friday, December 21, 2018 4:28:21 AM MST Walter Bright via Digitalmars-d wrote:
> On 12/20/2018 11:23 PM, Manu wrote:
> > and occasionally multiple implicit conversions.
>
> Another feature that looks great in the small, but turns into a hopeless morass all too quickly. Even C++ gave up on that, which meant it was pretty bad :-)
>
> (Basically, nobody could figure out which overload was being called and
> why.)

Honestly, over time, I've come to dislike implicit conversions more and more. They cause enough stray bugs with the built-in types without even getting into the issues with user-defined types (issues with implicit conversions with character type and implicit slicing of static arrays come to mind in particular, though the problem is by no means just with them). But what gets particularly bad is templated code. It's trivial to write code that's supposed to work on any type that implictly converts to a particular type but then fail to actually do the conversion in the code, resulting in subtle bugs. The primary fix for this is to _always_ force the conversion if you're writing templated code that is supposed to work with an implicit conversion, but in general, it just works better that the conversion occur outside of the template. So, taking all of that into account, it becomes easy to start viewing implicit conversions in general as being a terrible idea.

That being said, there are definitely times where implicit conversions are nice to have, and not having them can get pretty annoying. Also, casting is a blunt enough instrument that it can become easy to end up having explicit conversions that do the wrong thing (especially if the types involved get changed later without the code involving the case being updated). So, echewing implicit conversions can cause other problems (though on the whole, I do think that explicit conversions have far fewer problems - they just can get annoying sometimes).

But over time I've become increasingly worried about having the ability to have multiple alias this-es on a type. There's no question that there are times when it would be really useful, but with all of the problems surrounding even a single alias this, having multiple alias this-es on a type starts looking really risky. As it is, I think that having even a single alias this should be done with caution and relatively rarely. And if we had the ability to have multiple alias this-es on a type, I would think that it should be used extremely rarely. But the very fact that it existed could have some nasty repercussions (especially for generic code). I don't know that that means that we shouldn't have the feature, but it definitley concerns me.

- Jonathan M Davis

On 12/27/18 3:15 PM, Jonathan M Davis wrote:
> On Friday, December 21, 2018 4:28:21 AM MST Walter Bright via Digitalmars-d
> wrote:
>> On 12/20/2018 11:23 PM, Manu wrote:
>>> and occasionally multiple implicit conversions.
>>
>> Another feature that looks great in the small, but turns into a hopeless
>> morass all too quickly. Even C++ gave up on that, which meant it was
>> pretty bad :-)
>>
>> (Basically, nobody could figure out which overload was being called and
>> why.)

We don't have to copy what C++ did.

> 
> Honestly, over time, I've come to dislike implicit conversions more and
> more. They cause enough stray bugs with the built-in types without even
> getting into the issues with user-defined types (issues with implicit
> conversions with character type and implicit slicing of static arrays come
> to mind in particular, though the problem is by no means just with them).
> But what gets particularly bad is templated code. It's trivial to write code
> that's supposed to work on any type that implictly converts to a particular
> type but then fail to actually do the conversion in the code, resulting in
> subtle bugs. The primary fix for this is to _always_ force the conversion if
> you're writing templated code that is supposed to work with an implicit
> conversion, but in general, it just works better that the conversion occur
> outside of the template. So, taking all of that into account, it becomes
> easy to start viewing implicit conversions in general as being a terrible
> idea.

Well, implicit conversions of builtin types is not something a mere user can fix. I'd love to fix those problems, but the one DIP that was trying to fix a minuscule part of that was rejected for reasons that don't bode well for other parts.

But in terms of implicit casting that's user defined -- those things are fixable (if they are a problem).

Quite honestly, if alias this didn't exist, wrapping a type would be monstrously difficult. But it has to be implemented correctly (it's not right now).


> That being said, there are definitely times where implicit conversions are
> nice to have, and not having them can get pretty annoying. Also, casting is
> a blunt enough instrument that it can become easy to end up having explicit
> conversions that do the wrong thing (especially if the types involved get
> changed later without the code involving the case being updated).

Speaking of that, I believe it's possible to have a casting library that is similar to C++'s casting system. We should create one.

> 
> But over time I've become increasingly worried about having the ability to
> have multiple alias this-es on a type. There's no question that there are
> times when it would be really useful, but with all of the problems
> surrounding even a single alias this, having multiple alias this-es on a
> type starts looking really risky. As it is, I think that having even a
> single alias this should be done with caution and relatively rarely. And if
> we had the ability to have multiple alias this-es on a type, I would think
> that it should be used extremely rarely. But the very fact that it existed
> could have some nasty repercussions (especially for generic code). I don't
> know that that means that we shouldn't have the feature, but it definitley
> concerns me.

Having multiple alias this's would not increase any of the existing problems really, it just would add one more wrinkle of ambiguity. But I think that behavior should be easily defined and understood.

As for my own experience, I can't see myself using multiple alias this much at all, but it's definitely something that seems like an artificial limitation.

-Steve

On Thursday, 27 December 2018 at 20:15:04 UTC, Jonathan M Davis wrote:
> As it is, I think that having even a single alias this should be done with caution and relatively rarely. And if we had the ability to have multiple alias this-es on a type, I would think that it should be used extremely rarely. But the very fact that it existed could have some nasty repercussions (especially for generic code). I don't know that that means that we shouldn't have the feature, but it definitley concerns me.
>
> - Jonathan M Davis

Arguably, in a sense, we already have multiple alias this's. It just has to be done through 1 alias this per struct.


struct A {
  int a;
};

struct B {
    A a_;
    int b;
    alias a_ this;
}

struct C {
    B b_;
    int c;
    alias b_ this;
}

void main() {
    import std.stdio;

    C c;

    c.b = 10;
    c.a = 20;

    B b = c;
    A a = c;

    writeln( a, " ", b );
}

On Fri, Dec 28, 2018 at 12:25:14AM +0000, luckoverthere via Digitalmars-d wrote:
> On Thursday, 27 December 2018 at 20:15:04 UTC, Jonathan M Davis wrote:
> > As it is, I think that having even a single alias this should be done with caution and relatively rarely. And if we had the ability to have multiple alias this-es on a type, I would think that it should be used extremely rarely. But the very fact that it existed could have some nasty repercussions (especially for generic code). I don't know that that means that we shouldn't have the feature, but it definitley concerns me.
[...]
> Arguably, in a sense, we already have multiple alias this's. It just has to be done through 1 alias this per struct.
> 
> 
> struct A {
>   int a;
> };
> 
> struct B {
>     A a_;
>     int b;
>     alias a_ this;
> }
> 
> struct C {
>     B b_;
>     int c;
>     alias b_ this;
> }
[...]

That's not multiple alias this, that's just a chain of alias this's. A linear class inheritance hierarchy is not equivalent to multiple inheritance.


T

-- 
The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava

On Friday, 28 December 2018 at 00:36:15 UTC, H. S. Teoh wrote:
> On Fri, Dec 28, 2018 at 12:25:14AM +0000, luckoverthere via Digitalmars-d wrote:
>> On Thursday, 27 December 2018 at 20:15:04 UTC, Jonathan M Davis wrote:
>> > As it is, I think that having even a single alias this should be done with caution and relatively rarely. And if we had the ability to have multiple alias this-es on a type, I would think that it should be used extremely rarely. But the very fact that it existed could have some nasty repercussions (especially for generic code). I don't know that that means that we shouldn't have the feature, but it definitley concerns me.
> [...]
>> Arguably, in a sense, we already have multiple alias this's. It just has to be done through 1 alias this per struct.
>> 
>> 
>> struct A {
>>   int a;
>> };
>> 
>> struct B {
>>     A a_;
>>     int b;
>>     alias a_ this;
>> }
>> 
>> struct C {
>>     B b_;
>>     int c;
>>     alias b_ this;
>> }
> [...]
>
> That's not multiple alias this, that's just a chain of alias this's. A linear class inheritance hierarchy is not equivalent to multiple inheritance.
>
>
> T

Indeed, keen observation!

struct C {
    A a_;
    B b_;
    int c;

    alias a_ this;
    alias b_ this;
}

Sure you can arrange the structure differently and don't need to have one object contain another. Can have the same type for alias this'd. But in the context of the discussion of the comment I was replying to. It is possible to replicate the same feature of multiple alias this, as you can implicitly convert to multiple types.

On Fri, Dec 28, 2018 at 12:50:11AM +0000, luckoverthere via Digitalmars-d wrote: [...]
> struct C {
>     A a_;
>     B b_;
>     int c;
> 
>     alias a_ this;
>     alias b_ this;
> }
[...]

Compiler output:

	Error: there can be only one alias this

Nope, still no multiple alias this. :-D


T

-- 
Designer clothes: how to cover less by paying more.