On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

I'd be in favor of finally deprecating all sub-standard phobos module (moving them to https://github.com/dlang/undeaD) to make room for good implementations. Having a vacant place might be more encouraging than to wait for something better to come along.
Of course discussing which modules should be obsoleted is a tricky question.

std.signals
std.xml
std.outbuffer
std.socket
std.json // maybe ;)

I do not at all agree that a big language change is needed.
We just changed the lookup rules with http://dlang.org/changelog/2.071.0.html and managed to make this a transition instead of a break.
Also without a proposed feature list this discussion is somewhat lame.

On Wednesday, 14 June 2017 at 09:18:58 UTC, Jonathan M Davis wrote:
> If you're maintaining your code and making the occasional, required adjustments when the language or library changes something that requires adjustments, then you should be just fine without having to do massive code rewrites or anything like that (and at this point, breaking changes normally involve a deprecation process so that they don't just force you to immediately change your code).

That is my point exactly. I have nothing against evolving a language slowly over time to include more features. A few things get obsolete, ... no big issue. New options are added. Again. No big issue.

But the moment a language opens up for developers their "wishlist", it seems everybody wants "their" changes added to the language. And this then turn into a language that is constantly changing. That is consider more the worst case scenario.

Frankly, if things are handled in a evolutionary way, then i do not have a issue with it. As long as thing do not turn out into: "well, x percentage of your code just become useless".
;)

The main issue is library vs existing code. There is a lot of code out there that is now abandoned but still (mostly) works. The moment the evolution gets too far, your starting to get more and more code out there that simple does not work.

In my personal opinion, if you want to pull something like that, then make a totally complete clean break. Change the language name ... And yes it sounds radical and silly but if there is one frustrating point that people have new to a language, is legacy non-functional code.

I can right now look up Swift examples and get over 50% that simply do not work because the language evolved so fast and everybody used the name "Swift", not "Swift 1.0", "Swift 2.0"... Its frankly a mess. And while i personally love some of the features that Swift has, its a mess for anything outside of the pure Apple development.

Just putting the cards on the table but frankly D is a generic name ( Mars was not much better ). When Googling for D code, the results are hit or miss. When Googling for Dlang, it tries to search on GoLang. Marketing is hard when your product is so generic named ( double pun is intended ) :)

Just changing the library to D3 and not the base D name will result in people finding old code, not getting it to work, getting frustrated and simply ignoring the language. Hey, despite loving the syntax, did the exact same thing with Swift.

With D i can find 3 or 4 year old code and get it running something without a single issue. Or a quick fix. Just saying, its not just about the language and library features. it also about what is round the language. The examples and code out there, the packages, the editors and other support.

On Wednesday, 14 June 2017 at 11:34:09 UTC, Wulfklaue wrote:

> Just changing the library to D3 and not the base D name will result in people finding old code, not getting it to work, getting frustrated and simply ignoring the language. Hey, despite loving the syntax, did the exact same thing with Swift.
>
> With D i can find 3 or 4 year old code and get it running something without a single issue. Or a quick fix. Just saying, its not just about the language and library features. it also about what is round the language. The examples and code out there, the packages, the editors and other support.

D3 isn't going to happen. I ignored this thread as a result. I only read the most recent posts because I wanted to see why it hadn't died. I doubt that Phobos 2 will happen either. All comments I've read from Walter and Andrei indicate that there are no plans for either.

I've been using D for four years. I can still compile code that compiled with DMD at that time, with only a few minor modifications. I expect to be able to do the same four years from now.

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

> I think it's about time for D3 to start developing.

I would love to see a fork of D2 that attempts to address some obstacles I encountered when I was using D.  However, it is quite apparent that there is little to no interest in such a venture from those in the D community with the talent to actually do it.  And I have to admit there is still room for innovation in D2, and that seems to be where most want to allocate their limited resources.

For D3 to happen, it will likely require talent outside D's core team.

I do a lot of programming in different domains, and it seems I have to use a different language for each one in order to be productive. I would like to find a single language that I can use to program just about any domain, but still be able to enjoy modern features for safety, convenience, zero-cost abstractions, and modeling power.  I'm not aware of any language that fits that description, but the languages I've found to be somewhat close are C++11~17 and Rust.  They're the only ones that appear to be scalable down to domains such as resource constrained microcontrollers.

* Using D for resource constrained systems requires too many compromises and silly runtime hackery.
* C++11~17 is quite good but it is not at all convenient, and safety is just too easy to get wrong.
* Rust is probably the best, but it doesn't have the modeling power of D and C++.

It'd be more constructive to begin collecting information from the community about what changes they'd like to see in D3.  Here's a start from things just off the top of my head and in no particular order.

THINGS TO CHANGE OR ADD
-----------------------
* Final-by-default

* immutable by default

* @safe by default

* Fix attribute inconsistency and revisit if D is using the appropriate defaults

* Pay as you go druntime.
The compiler is too coupled to druntime and expects things to be there even though they're not required.  This would also make D a better language for replacing much of the exising infrastructure code out there that is currently written in C because it wouldn't require the D runtime dependency and all the overhead that goes with it.  Rust has done well in this regard.

* Minimal druntime
The language should be easy to port to other platforms.  Keep druntime small and to a few fundamental primitives to whatever extent that is possible.  Rust has also done well in this regard.

* Compiler resolves druntime symbols at compile time.
This is important for porting D to other platforms that may not have the resources or hardware to support certain features of the language.  The compiler would emit a compile-time error if usage of such a feature was attempted, but not supported by the runtime.  Proposed here [1].

* Some way to mark memory at compile-time with certain attributes (e.g. See [2]) to inform the compiler of proper code generation (e.g. volatile semantics).  This would probably only be useful for bare-metal programming, but I encounter this all the time and its getting worse with each new MCU generation.

* Remove the "module must be a file" arbitrary limitation
I ran into this when I was trying to model hundreds of memory-mapped IO registers.  I wanted to use a module for each register, but each module would only have a small amount of code, and I would have ended up with hundreds of little files.  It would have been better if I could group all "register" modules for a given peripheral under one "peripheral.d" package file.  Something like `package UART { module SR {} module DR{} }` would have been nice.  I ultimately ended up with `final abstract class {}` instead, which is stupid.

* get rid of the "_t" suffix added to types from C.
Come up with a better, more consistent naming convention for these types that doesn't carry baggage from other languages.

* Drop the GC or at a minimum make it opt-in.  Add a borrow checker, automatic reference counting, or some other GC alternative that doesn't require a separate thread.
DIP1000 is interesting and may enable some new interesting patterns and idioms.  Might be able to take some inspiration from it.  I wonder if DIP1000 would have been more elegant if D didn't have to worry about breaking code.

* The C standard library bindings and C++ standard library bindings should be in Deimos not in the druntime.
I already tried to promote this, but only encountered obstruction.

* Cure the TypeInfo infection [3]
TypeInfo has been over(ab)used in the runtime implementation.  This is probably due to historical baggage, but also a lack of discipline.

THINGS TO KEEP
--------------
* CTFE

* Templates and static-if (static-if is some powerful stuff!)

* Mixins (or some other way to do convenient composition)
I get that one should favor composition over inheritance, but most object oriented languages offer precious little to do the "right" thing.  D mixins are great for composition.

* Traits (or some other form of reflection)

* UFCS

THINGS TO DROP
--------------
* C++ interoperabiliy
Walter's right:  memory safety is going to kill C and C++ will go with it.  Don't waste time on this; it's not going to matter in 10 or 20 years.

After collecting such a list, begin a fork of LDC, and start working on it.  If you can show progress and potential, others may be willing to contribute, accelerating the project.  I, personally, think it would be very exciting to see and would eventually become an active contributor myself if the project addressed some of the issues I have with D2.

I was on cloud 9 when I first started using D, and had high hopes that it would change my career and even give me a new tool off which to build a profitable business.  But the more I used it, I just became more disillusioned.  D has so much potential compared to all other languages out there, but it's potential that it will never reach because it's just carrying too much baggage and has not been designed with domains like resource constrained microcontrollers in mind, like Rust was.

I don't do anything in D anymore, but I still watch what goes on here in the D community, and hope that someday enough people will come together and begin a fork to take D to its true potential.  I don't have the skills or resources at this time to lead such a project, but I'll volunteer my resources if it ever gets off the ground and shows promise.

Mike

[1] - Proposal to have druntime inform compiler of platform support - http://forum.dlang.org/post/psssnzurlzeqeneagora@forum.dlang.org
[2] - ARM Cortex-M3 memory attributes - https://developer.arm.com/products/processors/cortex-m/cortex-m3/docs/dui0552/latest/2-the-cortex-m3-processor/22-memory-model/221-memory-regions-types-and-attributes
[3] - Discussion about the TypeInfo infection - http://forum.dlang.org/post/nevipjrkdqxivoerftlw@forum.dlang.org

On Wed, 2017-06-14 at 11:57 +0000, bachmeier via Digitalmars-d wrote:
> 
[…]
> I've been using D for four years. I can still compile code that compiled with DMD at that time, with only a few minor modifications. I expect to be able to do the same four years from now.

I suggest this is the wrong view of backward compatibility.

If you have a code that is never to change then you should archive the compiler that compiled it along with that code. To demand that D must never fail to compile ancient code is just wrong.

If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
> * Rust is probably the best, but it doesn't have the modeling power of D and C++.

A lot of the points you mention, i also agree with but implementing that list is akin to writing a new language. You do not trow out the baby with the bathwater ;)

From what i am reading, you want D to be Rust. Personally, Rust make me want to tear out my eyes the moment you start with lifetimes, unwrapping and ownership all combined , its becomes almost unreadable.

>    fn the_longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
>        if s1.len() > s2.len() { s1 } else { s2 }
>    }

Rust really skips on the syntactic sugar *lol*.

If people want a low level language for microprocessors/plc, well they already got C++14/17 and Rust. D can carve its own market segment no? Why complicate D for one specific market segment?

There are defiantly nice point that you mention but dropping C/C++ support is like a dead sentence. D does not have the manpower and  libraries that people may need.

On 2017-06-14 11:38, Martin Nowak wrote:

> Also without a proposed feature list this discussion is somewhat lame.

You only need one, AST macros ;)

-- 
/Jacob Carlborg

On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
> If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow.

I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" then I most likely wouldn't use them and switch to something more stable...

So, I have no problem with Python going to Pyton3.x, as long as they update and maintain Python 2.7...

Ola Fosheim Grøstad wrote:

> On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
>> If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow.
>
> I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines"

at least C doesn't: almost all old-enough code is broken by various "UB".

On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:
> Ola Fosheim Grøstad wrote:
> 
> > On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
> > > If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow.
> > 
> > I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines"
> 
> at least C doesn't: almost all old-enough code is broken by various "UB".

The difference is that unlike D deprecations, the C code will still compile and appear to work (for the most part, anyway), thus giving people the illusion that their old code is still "OK".  When actually, the compiler may have done something unexpected with the UBs and thus inadvertently introduced security holes.

Of course, none of this matters, since when was the last time bad C code has caused security problems? :-P


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom