On 11/14/18 1:33 PM, jmh530 wrote:
> On Wednesday, 14 November 2018 at 17:33:27 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> The solution is cursors -- a "range" of a single element, which points at that element. You can iterate it just like a range (it has front, popFront, and empty), but it's used basically to mark the location you are interested in.
>>
>> dcollections used cursors, which I found much nicer. [snip]
> 
> I always thought the cursor approach you've discussed before was interesting, but I never played around with it much myself.
> 
> It looks to me like your cursor implementation operates similar to Optional types (as in the optional package). Does that make sense?

I haven't looked at it in depth, but the concept is probably the same. A cursor necessarily points at an element, and contains a boolean to denote emptiness.

The idea was a compromise to try and get the dcollections concept into Phobos. Originally, dcollections used iterators (and was D1). Ranges were added for the D2 port. Andrei wouldn't let it be considered for phobos, so I came up with the idea of making the iterators safe (and it actually is a nice concept too) by making them tiny ranges, but retaining the utility of an iterator for referencing.

In the end, Andrei built his own thing anyway, but the red black tree in phobos came from dcollections.

-Steve

On Wednesday, 14 November 2018 at 17:08:20 UTC, sepiasisy wrote:
> What bugs me is the shortening distance regarding what D has to offer with respect to C++.

I doubt the shortening distance. While C++ does advance and D isn't moving as fast as it was at 2010 (I think), I still believe C++ isn't the faster evolver of the two. When the next C++ standard comes out, D has improved too. Examples of what might be there by then:

-stable and reasonably documented DIP1000 implementation
-Dpp able to compile real-world c++ headers
-ability to script web pages and call the Web API without needing JavaScript glue code for that
-generally more stable implementation
-@nogc nothrow pure @safe containers that work with allocators and const/immutable

And if they're really going to add all that you listed and do it well, I don't think it will happen by 2020. Even if the standard catches that year, the implementations are unlikely to.

On Wed, Nov 14, 2018 at 05:44:35PM +0000, Stefan Koch via Digitalmars-d wrote: [...]
> newCTFE will blow away constexpr in perfomance!

Can't wait for newCTFE to be ready... any updates on the schedule?


> and when I have time for it, D will get type-manipulation abilities which are much more efficient than what you can do with templates.
> 
> it'll be faster to compile.

I want to hear more about this.  D's templates are darned powerful, and the syntax is far more readable (and writable!) than C++'s, but for certain use cases, like manipulating AliasSeq's (aka "type tuples") it's just not the right idiom, and often leads to quadratic or even exponential template expansion, which causes template bloat and often dog-slow.

Sometimes I find myself wishing that types were first-class compile-time "variables", and that you could write code that manipulates them directly, e.g., append a type to an array of types from inside a foreach loop, which is much more readable (and writable!) than a recursive template that you have to use today.


T

-- 
Answer: Because it breaks the logical sequence of discussion. / Question: Why is top posting bad?

On Wednesday, 14 November 2018 at 18:47:22 UTC, Dukc wrote:
> On Wednesday, 14 November 2018 at 17:08:20 UTC, sepiasisy wrote:
>> What bugs me is the shortening distance regarding what D has to offer with respect to C++.
>
> I doubt the shortening distance. While C++ does advance and D isn't moving as fast as it was at 2010 (I think), I still believe C++ isn't the faster evolver of the two. When the next C++ standard comes out, D has improved too. Examples of what might be there by then:
>
> -stable and reasonably documented DIP1000 implementation
> -Dpp able to compile real-world c++ headers
> -ability to script web pages and call the Web API without needing JavaScript glue code for that
> -generally more stable implementation
> -@nogc nothrow pure @safe containers that work with allocators and const/immutable
>
> And if they're really going to add all that you listed and do it well, I don't think it will happen by 2020. Even if the standard catches that year, the implementations are unlikely to.

If somebody says they are a C++ expert, they are in for an interesting time in an interview in some places, like with the people I work with and it usually ends up with well not like a world expert- I just meant I know C++ reasonably well.

If they deprecate old features and you never need to know them then maybe D eventually has a harder challenge to appeal to some.  But backwards compatibility is a basic value of the C++ comminity as I understand it as an observer.  Benefits to that, but it doesn't come for free.

Would you recommend somebody that knows scripting and used to program in Z80 assembler as a kid learn C++ as a practitioner when their job involves programming but also involves other things that create more value?  Maybe but it would definitely be a choice one could reasonably question.  Demonstrably it's not hard for such a person to learn D and they can be reasonably productive in it.

Again, it's a big wide world and the margin of language comparison is not always what you might think.  I never thought a significant commercial choice would be whether to replace Extended Pascal with D or Ada, but life is full of surprises and turns out that is the case.

Languages are about more than narrowly technical questions too - you can argue that some things are mere consequences of compiler and standard library implementations, but it's unavoidably true that the ecosystem and community are about values too.  There are broader consequences of language choice that result from those differences,as Joyent discovered with node.js

It doesn't do much good, I think,to worry about threats from perceived mighty competitors.  Steal ideas -giving due scholarly credit (to do so is a sign of strength and confidence too( - from wherever one may find them.  But it makes more sense to worry about making D the best language it can be - for a broad interpretation of language.

It's easy being the underdog because to grow at a decent compounded rate you can just gain users from wherever you find them, and it really doesn't need to be a battle to the death.  Life isn't a zero sum game and I doubt the number of people writing native code as part of their job has peaked.

DPP already helps I think.  As does dstep.  Don't forget also the work to get STL types into druntime.

Well you're right,D does have fewer libraries.  Only 1400 on code.dlang.  But you also have all of C.  And I guess being able to use most of C++ will be a gain again also because it helps with incremental transitions of larger code bases.  Might still be some problems where you can't represent C++ types in D, but ask Atila about that.
It's easier for D than for Rust in this respect.

Being able to access C# libraries in D would be nice.  That's a next project (we have been working on autowrap for C# the other way around).  Dmitry Olshhansky told me about Graal.  For interop on JVM that doesn't look too bad.  No promises but I think something useful shouldn't be too bad to get to.  Won't really know till we try.

If one can use in future D,C,C++, Python,C#,Java libraries from D in a pleasant enough way that would be okay, wouldn't it ?

Remaining questions are stability, quality and tooling.  First two are already a lot better and I guess will be pretty good in time?  I don't know on the tooling how much it might cost or how it would be accomplished.

On 2018-11-14 20:23, H. S. Teoh wrote:

> I want to hear more about this.  D's templates are darned powerful, and
> the syntax is far more readable (and writable!) than C++'s, but for
> certain use cases, like manipulating AliasSeq's (aka "type tuples") it's
> just not the right idiom, and often leads to quadratic or even
> exponential template expansion, which causes template bloat and often
> dog-slow.
> 
> Sometimes I find myself wishing that types were first-class compile-time
> "variables", and that you could write code that manipulates them
> directly, e.g., append a type to an array of types from inside a foreach
> loop, which is much more readable (and writable!) than a recursive
> template that you have to use today.

That's exactly what he's referring to (correct me if I'm wrong).

-- 
/Jacob Carlborg

On Wed, 2018-11-14 at 19:39 +0000, Laeeth Isharc via Digitalmars-d wrote: […]
> 
> If somebody says they are a C++ expert, they are in for an interesting time in an interview in some places, like with the people I work with and it usually ends up with well not like a world expert- I just meant I know C++ reasonably well.

At the ACCU conference (https://conference.accu.org ) if someone says they are
a C++ expert, they are probably a member of WG21. ;-)

(For the uninitiated WG21 is the C++ standards committee.)

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, 14 November 2018 at 18:47:22 UTC, Dukc wrote:
> [snip]
>
> -stable and reasonably documented DIP1000 implementation
> -Dpp able to compile real-world c++ headers
> -ability to script web pages and call the Web API without needing JavaScript glue code for that
> -generally more stable implementation
> -@nogc nothrow pure @safe containers that work with allocators and const/immutable

A lot of the stuff that Walter seems focused on like DIP1000 and converting the backend to D seems like stuff that is very valuable, but doesn't necessarily have a big immediate payoff. More like an investment in the future with nebulous (probably large) payoffs down the road. That's probably contributing to some people's sense of frustration.

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:
> * Modules

Not really, what C++ only will achieve is to leave out header files but no name spacing is supported due to backward compatibility.
C++ modules aren't mapped to directories/files as it is in Java, still you get fu**ed with the wonderful C/C++ toolchain of cmake, make and bash.

>D will get type-manipulation abilities which are much more efficient than what you can do with templates

In which regard?

>Sometimes I find myself wishing that types were first-class compile-time "variables"

Types as values would be a nice option as can be seen by idris or the zig language.

>e.g., append a type to an array of types from inside a foreach loop, which is much more readable (and writable!) than a recursive template that you have to use today.

Absolutely.

On Wednesday, 14 November 2018 at 18:47:22 UTC, Dukc wrote:
> On Wednesday, 14 November 2018 at 17:08:20 UTC, sepiasisy wrote:
>> What bugs me is the shortening distance regarding what D has to offer with respect to C++.
>
> I doubt the shortening distance. While C++ does advance and D isn't moving as fast as it was at 2010 (I think), I still believe C++ isn't the faster evolver of the two. When the next C++ standard comes out, D has improved too. Examples of what might be there by then:

Me, C++ reminds me more and more of the Borg from Star Trek NG.
Resistance is futile; your features will be assimilated. And assimilitated it will, in a big pile of ducts and things going everywhere, ugly as hell and with no apparent logical purpose. Having also the aura of invincibility but defeated in every time by a small glitch that noone, the least the collective itself, foresaw because of the weight of the complexity.

Sorry for that not quite professional jab, but that's what it reminds me.

On Wednesday, 14 November 2018 at 19:39:42 UTC, Laeeth Isharc wrote:
> DPP already helps I think.  As does dstep.  Don't forget also the work to get STL types into druntime.

I agree. In my opinion, an issue with DPP and related work is that
they are difficult to follow outside of the D community. Most of
the time this forum is the only source of information regarding
the language.

It's not that I don't follow what goes on in this forum (I check
almost daily), yet I don't know what is the current progress on DPP
(or newCTFE).

> If one can use in future D,C,C++, Python,C#,Java libraries from D in a pleasant enough way that would be okay, wouldn't it ?
>
> Remaining questions are stability, quality and tooling.  First two are already a lot better and I guess will be pretty good in time?  I don't know on the tooling how much it might cost or how it would be accomplished.

Pretty much agree.