December 21, 2018
On 12/21/18 5:23 PM, Steven Schveighoffer wrote:

> And your example from earlier:
> 
> class C : B
> {
>    B b;
>    alias b this;
> }

FYI, this already prints a compiler error, which is exactly the right behavior!

Error: alias this is not reachable as C already converts to onlineapp.B

-Steve
December 21, 2018
On Fri, Dec 21, 2018 at 01:46:45PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/21/2018 11:08 AM, Steven Schveighoffer wrote:
[...]
> > But MI is not multiple alias-this.
> 
> It fundamentally is. (Though I agree it doesn't have the virtual base
> "diamond inheritance" issue.)

It doesn't have to be.  It can be treated as imports: if there's any question about what a symbol should resolve to, emit an ambiguity error.


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
December 21, 2018
On Friday, 21 December 2018 at 21:42:35 UTC, Walter Bright 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.
>
> Javascript has been incredibly successful as an embedded language in web pages.

Now that web assembly has arrived, C++ is a perfectly suitable language for the browser.  I'm predicting Javascript will become a legacy language for the web in 5 years.

I recently wrote 2 applications in C# web assembly (using Blazor) and they probably took me 20% of the time had I needed to write a backend in C# and a frontend in Javascript.  It was an awesome, eye-opening experience, and I'm never going back.

There may still be a need for Javascript for a few things, but not many.  Javascript's days are numbered.  IMO, C#, C++, Rust, and other general purpose languages that can compile to web assembly is where it's at for the future of the web.  And, I don't see why D can't be a major player there, as I know it already has been demonstrated to be:  https://forum.dlang.org/post/zwmszfalyeprtyyhxfeq@forum.dlang.org

Mike


December 21, 2018
On Fri, Dec 21, 2018 at 10:53:28PM +0000, Mike Franklin via Digitalmars-d wrote:
> On Friday, 21 December 2018 at 21:42:35 UTC, Walter Bright 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.
> > 
> > Javascript has been incredibly successful as an embedded language in web pages.
> 
> Now that web assembly has arrived, C++ is a perfectly suitable language for the browser.  I'm predicting Javascript will become a legacy language for the web in 5 years.

Although I agree with the sentiment that, in the long term, Javascript is a dead-end, I really doubt that it would become obsolete in 5 years. I'm expecting it will be more like 15-20 years, give or take.


> I recently wrote 2 applications in C# web assembly (using Blazor) and they probably took me 20% of the time had I needed to write a backend in C# and a frontend in Javascript.  It was an awesome, eye-opening experience, and I'm never going back.

That's awesome, and in retrospect, not at all surprising, given the -- shall we call it, idiosyncrasies? -- of Javascript. While modern Javascript has come a long way since the early days of "on click, display an annoying flashing marquee", it has never been able to overcome the fundamental design limitations it inherited from those days. Writing non-trivial code in Javascript is an exercise in masochism, and I've had to *maintain* such code in the past. A nightmarish experience I would not wish on anyone.


> There may still be a need for Javascript for a few things, but not many.  Javascript's days are numbered.  IMO, C#, C++, Rust, and other general purpose languages that can compile to web assembly is where it's at for the future of the web.  And, I don't see why D can't be a major player there, as I know it already has been demonstrated to be: https://forum.dlang.org/post/zwmszfalyeprtyyhxfeq@forum.dlang.org
[...]

While I still have qualms about the idea of running arbitrary code in a browser (no matter how encapsulated the sandbox is claimed to be), I *would* quite look forward to the day when I don't have to touch Javascript in order to deploy code on the web. Especially if said deployment can be done in D!


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
December 22, 2018
On Friday, 21 December 2018 at 21:42:35 UTC, Walter Bright wrote:
> On 12/21/2018 3:54 AM, Atila Neves wrote:
>> On Friday, 21 December 2018 at 11:25:18 UTC, Walter Bright wrote:
>>> Probably because Lisp is unusable without macros,
>> 
>> Lisp is perfectly usable without macros,
>
> Technically true. Doubtful that is pragmatically true once a program exceeds a certain size.

As true as a C program of the same size. They're just better than not using them. I have difficulty not writing macros when I write Lisp, but then again I have difficulty not writing templates when I write C++ or D.

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

> Javascript has been incredibly successful as an embedded language in web pages.

It has. But with webassembly its days might be numbered.


December 24, 2018
On 12/21/2018 2:43 PM, H. S. Teoh wrote:
> It can be treated as imports:

See my response to Timon.

December 24, 2018
On Monday, 24 December 2018 at 11:46:46 UTC, Walter Bright wrote:
> On 12/21/2018 2:43 PM, H. S. Teoh wrote:
>> It can be treated as imports:
>
> See my response to Timon.

My 2 cents is that D needs to allow custom implicit conversion without using alias this.(You shouldn't have to rely on alias this, to get implicit conversations!)
December 24, 2018
On Mon, Dec 24, 2018 at 04:51:09PM +0000, 12345swordy via Digitalmars-d wrote:
> On Monday, 24 December 2018 at 11:46:46 UTC, Walter Bright wrote:
> > On 12/21/2018 2:43 PM, H. S. Teoh wrote:
> > > It can be treated as imports:
> > 
> > See my response to Timon.
> 
> My 2 cents is that D needs to allow custom implicit conversion without using alias this.(You shouldn't have to rely on alias this, to get implicit conversations!)

>From what I understand, Walter dislikes implicit conversions because of
the horrible mess in C++ caused by implicit conversions and the associated obfuscated tangle of rules that nobody except language lawyers would even begin to understand.


T

-- 
Старый друг лучше новых двух.
December 24, 2018
On Monday, 24 December 2018 at 17:08:33 UTC, H. S. Teoh wrote:
> From what I understand, Walter dislikes implicit conversions because of
> the horrible mess in C++ caused by implicit conversions and the associated obfuscated tangle of rules that nobody except language lawyers would even begin to understand.
>
>
> T

I understand his concerns. However it doesn't change the fact that people use alias this as way of implicit casting, and people desire custom implicit conversions!
*** We can introduce implicit conversations without introducing the mess that is C++!***

Alex

December 24, 2018
On Mon, Dec 24, 2018 at 05:54:45PM +0000, 12345swordy via Digitalmars-d wrote:
> On Monday, 24 December 2018 at 17:08:33 UTC, H. S. Teoh wrote:
> > From what I understand, Walter dislikes implicit conversions because of the horrible mess in C++ caused by implicit conversions and the associated obfuscated tangle of rules that nobody except language lawyers would even begin to understand.
[...]
> I understand his concerns. However it doesn't change the fact that
> people use alias this as way of implicit casting, and people desire
> custom implicit conversions!
> *** We can introduce implicit conversations without introducing the
> mess that is C++!***
[...]

If you can convince him, that would be great!


T

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