www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP66 has been approved contingent to a few amendments as noted

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Congratulations, Igor! -- Andrei
Dec 23 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 07:49:47 -0800
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:


 Congratulations, Igor! -- Andrei


i can't believe my eyes! congrats, and thanks to all people who was
working on it, either by contributing code or by contributing time to
discuss and settle the things!
Dec 23 2014
prev sibling next sibling parent reply "Vic" <vic apakau.com> writes:
http://wiki.dlang.org/DIP66

One more feature.


On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu 
wrote:

 Congratulations, Igor! -- Andrei
Dec 23 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Dec 23, 2014 at 11:05:05PM +0000, Vic via Digitalmars-d wrote:

 
 http://wiki.dlang.org/DIP66
 
 One more feature.


[...]

Which has been promised by TDPL years ago and only now become fully
implemented.


T

-- 
One disk to rule them all, One disk to find them. One disk to bring them all
and in the darkness grind them. In the Land of Redmond where the shadows lie.
-- The Silicon Valley Tarot
Dec 23 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 06:13:43 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Tue, Dec 23, 2014 at 11:05:05PM +0000, Vic via Digitalmars-d 
 wrote:

 
 http://wiki.dlang.org/DIP66
 
 One more feature.


 [...]

 Which has been promised by TDPL years ago and only now become 
 fully implemented.


Is TDPL the language spec? As I've pointed out before "multiple 
alias this" was implemented in Self, then removed because it was 
considered confusing and not useful. "lazy" was implemented in 
Algol and then shunned in just about all languages that followed. 
Time for D to learn from history...
Dec 23 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 24 December 2014 at 06:18:56 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 24 December 2014 at 06:13:43 UTC, H. S. Teoh via 
 Digitalmars-d wrote:

 On Tue, Dec 23, 2014 at 11:05:05PM +0000, Vic via 
 Digitalmars-d wrote:

 
 http://wiki.dlang.org/DIP66
 
 One more feature.


 [...]

 Which has been promised by TDPL years ago and only now become 
 fully implemented.


 Is TDPL the language spec?


Pretty much yes. It is a bit obsolete here and there but it does 
not have any speculation, only actual design intentions.


 As I've pointed out before "multiple alias this" was 
 implemented in Self, then removed because it was considered 
 confusing and not useful. "lazy" was implemented in Algol and 
 then shunned in just about all languages that followed. Time 
 for D to learn from history...


Whatever.
Dec 24 2014
prev sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 24/12/2014 06:18, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 "lazy" was implemented in Algol and then shunned in just about all
 languages that followed.


FWIW Apple's recent Swift has  autoclosure, which is the same as lazy. 
It's needed to implement assert in Swift.
Dec 27 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 27 December 2014 at 12:32:32 UTC, Nick Treleaven 
wrote:

 On 24/12/2014 06:18, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 "lazy" was implemented in Algol and then shunned in just about 
 all
 languages that followed.


 FWIW Apple's recent Swift has  autoclosure, which is the same 
 as lazy. It's needed to implement assert in Swift.


Yes...

«As with macros in C, auto-closures are a very powerful feature 
that must be used carefully because there is no indication on the 
caller side that argument evaluation is affected.»

https://developer.apple.com/swift/blog/?id=4
Dec 27 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-12-27 13:32, Nick Treleaven wrote:


 FWIW Apple's recent Swift has  autoclosure, which is the same as lazy.
 It's needed to implement assert in Swift.


Doesn't Scala have something similar.

-- 
/Jacob Carlborg
Dec 27 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 27 December 2014 at 15:13:07 UTC, Jacob Carlborg 
wrote:

 On 2014-12-27 13:32, Nick Treleaven wrote:


 FWIW Apple's recent Swift has  autoclosure, which is the same 
 as lazy.
 It's needed to implement assert in Swift.


 Doesn't Scala have something similar.


Yes, both Simula and Scala provide call-by-name.
Dec 27 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu 
wrote:

 Congratulations, Igor! -- Andrei


Good to see that.

It is a big feature though with a notable impact on symbol 
resolution. How about providing it as a separate compiler build 
for a release or two before deploying as part of master?
Dec 24 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:



 resolution. How about providing it as a separate compiler build


I feel like dropping D1 was not such a good move. Especially if 
full ABI compatibility with D2, people could have chose to write 
some of the less critical modules of their software in D2 (along 
with the enthusiasm of discovery), while still having a 
stable&non-experimental compiler for the really critical things.

Then, D1 would have become D1.5 by integrating the D2 time-proven 
features etc., just as D2 could become D2.5.

Is too late (or undesired) to resurrect D1 in maintenance mode? 
It is a bit strange that one of the most successful stories of D 
(Sociomantic) uses D1, still the compiler is ignored and 
everybody seems pretending that is a D (D2) success story.
Dec 24 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:



 resolution. How about providing it as a separate compiler build


 I feel like dropping D1 was not such a good move. Especially if 
 full ABI compatibility with D2, people could have chose to 
 write some of the less critical modules of their software in D2 
 (along with the enthusiasm of discovery), while still having a 
 stable&non-experimental compiler for the really critical things.


In my opinion whole D1 vs D2 dichotomy could have been avoided if 
not design decisions for very few language parts that cause 90% 
of trouble - this comes from currently porting Sociomantic 
projects to D2. I am going to write some blog posts about it 
pretty soon.

ABI compatibility is hard though, it does not currently exist 
even between different D2 releases.


 Then, D1 would have become D1.5 by integrating the D2 
 time-proven features etc., just as D2 could become D2.5


This pretty much means using proper semantic versioning as 
inherent part of development / release process - something I'd 
like to see a lot but impossible until it is acknowledged by 
those who actually work on compiler.


 Is too late (or undesired) to resurrect D1 in maintenance mode? 
 It is a bit strange that one of the most successful stories of 
 D (Sociomantic) uses D1, still the compiler is ignored and 
 everybody seems pretending that is a D (D2) success story.


What would be the point of it? D1 is almost absolutely inferior 
to D2 (both compiler and language) and lacks any better tools 
recently created by the community. Only reason why D1 is still 
used here is huge effort investment to actually port that much 
code without ever delaying normal deployment schedule - and I am 
working on this to change :)
Dec 24 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:







 What would be the point of it? D1 is almost absolutely inferior 
 to D2 (both compiler and language) and lacks any better tools 
 recently created by the community.


I do not contest that. But will be a less-deceiving entry-point 
for those that are new to the language, they will bite and would 
wish to see more...

And it would relieve time pressure on the current D2 development, 
that thrives to be both innovative and production-ready at the 
same time.

D2 is still looking for the best design. D1 has one, is not as 
good, but is a safer default.

Anyway, I do not push for it.
Dec 24 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:







 What would be the point of it? D1 is almost absolutely 
 inferior to D2 (both compiler and language) and lacks any 
 better tools recently created by the community.


 I do not contest that. But will be a less-deceiving entry-point 
 for those that are new to the language, they will bite and 
 would wish to see more...


It sounds like you have overly positive memories of D1. Working 
with it daily and especially dealing with all the compiler bugs 
we had back then (and still have with dmd1) - it is hardly an 
experience I'd want newcomer to have. Lacking quality of the 
toolchain kills any benefit from the language simplicity.
Dec 27 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:


 It sounds like you have overly positive memories of D1. Working 
 with it daily and especially dealing with all the compiler bugs 
 we had back then


I used to find a new D1 compiler bug about every 20 lines of my 
code. This isn't nice.

Bye,
bearophile
Dec 27 2014
prev sibling next sibling parent reply "newbe" <none none.com> writes:
does that mean, that sociomantics is writing crappy, fault prone
and unusable software?
they are the praised light on D's sky when evangelizing D, even
if everybody thinks they are using D2.
are they dumb or just uneducated?



On Saturday, 27 December 2014 at 14:27:09 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot 
 wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:







 What would be the point of it? D1 is almost absolutely 
 inferior to D2 (both compiler and language) and lacks any 
 better tools recently created by the community.


 I do not contest that. But will be a less-deceiving 
 entry-point for those that are new to the language, they will 
 bite and would wish to see more...


 It sounds like you have overly positive memories of D1. Working 
 with it daily and especially dealing with all the compiler bugs 
 we had back then (and still have with dmd1) - it is hardly an 
 experience I'd want newcomer to have. Lacking quality of the 
 toolchain kills any benefit from the language simplicity.
Dec 27 2014
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 27 December 2014 at 14:59:58 UTC, newbe wrote:

 does that mean, that sociomantics is writing crappy, fault prone
 and unusable software?
 they are the praised light on D's sky when evangelizing D, even
 if everybody thinks they are using D2.
 are they dumb or just uneducated?


That means that they have huge working code base that can be just 
simply switched to different language version. If using inferior 
toolchain didn't result in productivity losses no one would 
bother upgrading even now.

There is certain sympathy towards D1 as a _language_ but compiler 
quality as well as toolchain infrastructure is simply 
non-existent. I dream of being able to use DScanner, mono-d, 
dfix, ldc/gdc and similar cool things at work.
Dec 27 2014
prev sibling parent reply "eles" <eles215 gzk.dot> writes:
On Saturday, 27 December 2014 at 14:27:09 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot 
 wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:











 It sounds like you have overly positive memories of D1. Working 
 with it daily and especially dealing with all the compiler bugs 
 we had back then (and still have with dmd1) - it is hardly an 
 experience I'd want newcomer to have. Lacking quality of the 
 toolchain kills any benefit from the language simplicity.


Ypu are comparing the D2 toolchain from today with the D1 
toolchain from back then (as the work on the latter stalled when 
the language was retired, and the bulk of the work on D2 
toolchain - and language - was done in the last 1.5-2 years).

Back then I doubt that D2 toolchain was in better shape than D1. 
Yes, the latter was doomed by the Phobos vs Tango issue, but that 
wasn't the fault of the language.

But I do not discuss about toolchains, but about the language 
versions (D1 and D2) themselves. Please, for the remaininig of 
the discussion, let's not mix the language and the toolchain.

Point is, after so many years, D in its current incarnation (D2) 
is in the same recurring stage (and I speak about the language): 
on one hand, need to tie up some knots and ensure consistency and 
stability of the language. On the other hands, the need to modify 
the curren design and implement nicer features. I feel that the 
two conflict too much already.

OTOH, D2's design is far from reaching the ideal, and many ideas 
needs pushing the frontier even further.

The approach that I had in mind was to let D1 there for peple who 
need to compile code and let D2 also there for people who need to 
innovate their code. Then, once a feature is tested and re-tested 
and the design of it is concidered to be optimal, it is migrated 
from D2 to D1. It doesn't need to be immediately, but over a span 
that could e even 6 months. People will have time to adapt their 
skills and their code to integrate (or take advantage) of the new 
feature.

Then, the new frontlines would become D1.1 and D2.1.
Dec 27 2014
next sibling parent "newbe" <none none.com> writes:
+1

You are stating the situation absolutely correct! Exactly the
same is happening now what happened with the decision to get a
release version D1 and start with D2.
it has been an experiment ever since with D2 and I quit the rat
race - keeping up with bad docs, features I don't need etc..



On Saturday, 27 December 2014 at 16:10:57 UTC, eles wrote:

 On Saturday, 27 December 2014 at 14:27:09 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot 
 wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:











 It sounds like you have overly positive memories of D1. 
 Working with it daily and especially dealing with all the 
 compiler bugs we had back then (and still have with dmd1) - it 
 is hardly an experience I'd want newcomer to have. Lacking 
 quality of the toolchain kills any benefit from the language 
 simplicity.


 Ypu are comparing the D2 toolchain from today with the D1 
 toolchain from back then (as the work on the latter stalled 
 when the language was retired, and the bulk of the work on D2 
 toolchain - and language - was done in the last 1.5-2 years).

 Back then I doubt that D2 toolchain was in better shape than 
 D1. Yes, the latter was doomed by the Phobos vs Tango issue, 
 but that wasn't the fault of the language.

 But I do not discuss about toolchains, but about the language 
 versions (D1 and D2) themselves. Please, for the remaininig of 
 the discussion, let's not mix the language and the toolchain.

 Point is, after so many years, D in its current incarnation 
 (D2) is in the same recurring stage (and I speak about the 
 language): on one hand, need to tie up some knots and ensure 
 consistency and stability of the language. On the other hands, 
 the need to modify the curren design and implement nicer 
 features. I feel that the two conflict too much already.

 OTOH, D2's design is far from reaching the ideal, and many 
 ideas needs pushing the frontier even further.

 The approach that I had in mind was to let D1 there for peple 
 who need to compile code and let D2 also there for people who 
 need to innovate their code. Then, once a feature is tested and 
 re-tested and the design of it is concidered to be optimal, it 
 is migrated from D2 to D1. It doesn't need to be immediately, 
 but over a span that could e even 6 months. People will have 
 time to adapt their skills and their code to integrate (or take 
 advantage) of the new feature.

 Then, the new frontlines would become D1.1 and D2.1.
Dec 27 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
You can't speak about resurrecting language without considering 
costs of resurrecting the toolchain - unless one wants to write 
programs exclusively with pen and paper of course.

But I do recognize the troll pattern now, thanks.
Dec 27 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 27 December 2014 at 16:44:35 UTC, Dicebot wrote:

 You can't speak about resurrecting language without considering 
 costs of resurrecting the toolchain - unless one wants to write 
 programs exclusively with pen and paper of course.

 But I do recognize the troll pattern now, thanks.


Shh... It is possible to strip down D2.
Dec 27 2014
prev sibling next sibling parent reply "newbe" <none none.com> writes:
troll? it doesn't fit your opinion?

well I won't write anymore - therefore you win.



On Saturday, 27 December 2014 at 16:44:35 UTC, Dicebot wrote:

 You can't speak about resurrecting language without considering 
 costs of resurrecting the toolchain - unless one wants to write 
 programs exclusively with pen and paper of course.

 But I do recognize the troll pattern now, thanks.
Dec 27 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 27 Dec 2014 16:50:34 +0000
newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 troll? it doesn't fit your opinion?
=20
 well I won't write anymore - therefore you win.


bingo!
Dec 27 2014
prev sibling parent "eles" <eles215 gzk.dot> writes:
On Saturday, 27 December 2014 at 16:44:35 UTC, Dicebot wrote:

 You can't speak about resurrecting language without considering 
 costs of resurrecting the toolchain - unless one wants to write 
 programs exclusively with pen and paper of course.


That's true, because the gap in developping the toolchain 
accumulated. The alternative would be to stall D2 at the current 
language state and start D3 with the main target being the memory 
management pardigm.

I kinda doubt that RC and other management techniques will 
integrate smoothly into D2. And is not the breakages that I worry 
about, it is that the language could become a behemoth with many 
legs and no head. That is, will loose streamilness.


 But I do recognize the troll pattern now, thanks.


With all respect, but you are looking into a mirror while taking 
it for a window.
Dec 27 2014
prev sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24/12/14 15:27, eles via Digitalmars-d wrote:

 D2 is still looking for the best design. D1 has one, is not as good, but is a
 safer default.


Honestly, developing in D1, I personally feel that this is not so much a stable 
version as a frozen snapshot of a still-evolving language.  There are just too 
many idiosyncrasies and inconsistencies in its design (for example, the way in 
which dynamic/static/associative arrays behave).

Now, that said, in practice D1 does feel for the most part very much like a 
subset of D2 features; you could code a new project in D2, using the same
design 
principles, and have pretty much identical results.  So it's entirely fair to 
see a D success story here.

With more historical resources, it might have been sane or possible to backport 
some of the relevant breaking changes -- that is, to have a D1.5 with the same 
reduced feature set but with the inconsistencies and bad design decisions
ironed 
out -- but now that D2 has reached its current state, it doesn't seem worth it 
to me.  D2 may still be evolving, but it's stable _enough_, and with good
change 
management (e.g. the -dip flag as discussed here) there's nothing on a 
_language_ basis that seems other than an improvement (Dicebot may have some 
counter-examples to hand, but off the top of my head, I can't think of any:-).

I suppose that we could, today, divide D2 into a guaranteed stable subset and a 
wider range of features whose final design is still up for discussion, but even 
that seems non-trivial: cf. the kerfuffle over whether class methods should be 
virtual or final by default.  (And no, please don't take this as a reason to 
re-open that discussion.)

The simple, straightforward fact is that it's hard to upgrade a large codebase 
with high performance requirements.  That's not a judgement on D2 as a 
production-ready language.
Dec 28 2014
parent reply "eles" <eles eles.com> writes:
On Sunday, 28 December 2014 at 12:10:15 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

 On 24/12/14 15:27, eles via Digitalmars-d wrote:

 D2 is still looking for the best design. D1 has one, is not as 
 good, but is a
 safer default.


 Honestly, developing in D1, I personally feel that this is not 
 so much a stable version as a frozen snapshot of a 
 still-evolving language.


Yes, because D1 is just that. It was already a D2 in the making 
at that time and D1 was stopped not because it has reached a 
significant milestone, but simply because Andrei bet everything 
on D2 and wanted all resources concentrated on it.

But D1 might be dead, the question of stability s experiment 
remains.

As Ola wisely observed, the debate is not about D1 per sé, but 
about the moving target that one chases when (trying to) use(ing) 
D.

Instead of D1 and D2, think D2 and D3 or, if you like, stableD 
and experimentD. Place the border between them wherever you want, 
but before changing the paradigm of memory management.

In the original comment to which I replied with the proposal of 
D1 back again, the trigger was "different build". Just re-read 
that post and replace D1 with "different (aka stable) build" and 
re-shape the ideas accordingly.

Why that? Well, as Walter stated several times, using a new 
memory management technique is not only about having a new 
compiler and memory management mechanism. It is also (and mainly) 
about *coding style*. When developing for a GC-based language, 
one makes some assumptions and writes some code accordingly. When 
developing for a RC-based language, one writes *different* code. 
And when writing for MM-based language, one structures and writes 
another kind of code.

Thing is, by now, most of D2 code that is written is GC-centric. 
Supporting that to at least the same level of performance, while 
making sure the impact of the new changes that should allow RC 
and MM techniques, along with the work on a 
precise/concurrent/performant GC, while letting room for the new 
memory paradigm to provide optimized code (and not asking changes 
in the coding style)... is too much.

Even much too much given the other untied knots that D has: from 
properties, multiple aliasing this, re-definition of "scope" and 
C++ compatibility. I am sure there are others too.

And you charge this already unstable state with a new mechanism 
of memory management that is yet to be designed, not to say about 
being written? Now oua re introducing -dip= flags, which could 
work as long as they are orthogonal with existing code but... for 
how long and how? Will every project come with a .ini file that 
will list the dips that are necessary for that project to work?

"This project is not written in D1, but in 
D2+dip63,+dip45+dip119v3,+dip23 and incompatible with dip22 and 
dip99. For best performance we recommend disabling dip67 and use 
the dmd source version 2a2b3c4ddf2a"?

What about tying up the current issues that keep running in 
circles, a lot of eternally to be deprecated features and so on? 
They will be let for 2025? Will drag properties issues and the 
others (*complex types, anyone*?) until then?

Don clearly stated in one of hist posts: "keeping deprecated 
features has a cost!". It works for one of the most successful 
stories in the D world. Guess its name? Sociomantic!


 Now, that said, in practice D1 does feel for the most part very 
 much like a subset of D2 features; you could code a new project 
 in D2, using the same design principles, and have pretty much 
 identical results.  So it's entirely fair to see a D success 
 story here.


Except that porting this subset to its own takes quite some time 
for Sociomantics...


 With more historical resources, it might have been sane or 
 possible to backport some of the relevant breaking changes -- 
 that is, to have a D1.5 with the same reduced feature set but 
 with the inconsistencies and bad design decisions ironed out -- 
 but now that D2 has reached its current state, it doesn't seem 
 worth it to me.


I agree with that. But the point is, D2 has been also reached a 
state where is too much on its plate in terms of contradiction 
between "be-production-ready!" and "be-innovative!". Not even to 
say "clean up all the dark corners!".

Everybody keeps replying with "that was then and a decision was 
made back then!". I am saying "hey! this happens again!".


 I suppose that we could, today, divide D2 into a guaranteed 
 stable subset and a wider range of features whose final design 
 is still up for discussion, but even that seems non-trivial: 
 cf. the kerfuffle over whether class methods should be virtual 
 or final by default.  (And no, please don't take this as a 
 reason to re-open that discussion.)


No, I do not start that discussion. Thing is, you cannot add 
zillions of flags that basically make you jumping from a language 
to another every time that you compile code. This way, what about 
adding some new flags like "-java", "-csharp" and 
"-c++1zwithconceptsliteandmodules"?

The only thing that those flags will have in common with D and 
with each other will be the fact that they are all braces-family 
languages. That, and nothing more than that. (yes, yes, it's an 
exaggeration).
Dec 28 2014
parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28/12/14 21:08, eles via Digitalmars-d wrote:

 Thing is, by now, most of D2 code that is written is GC-centric.


With some exceptions (e.g. embedded programming), the assumption of a GC isn't 
so much a problem as the fact that too many parts of Phobos have been written
in 
a way that doesn't allow you to avoid generating garbage (e.g. by passing in 
preallocated buffers or suchlike).


 And you charge this already unstable state with a new mechanism of memory
 management that is yet to be designed, not to say about being written?


I'm really not sure who this "you" is that you're talking about.


 "This project is not written in D1, but in D2+dip63,+dip45+dip119v3,+dip23 and
 incompatible with dip22 and dip99. For best performance we recommend disabling
 dip67 and use the dmd source version 2a2b3c4ddf2a"?


... will only happen if the project is slow about reviewing implemented DIPs. 
To my mind it would be a pretty bad show if any one -dip flag hung about for 
longer than a couple of compiler releases.


 Don clearly stated in one of hist posts: "keeping deprecated features has a
 cost!". It works for one of the most successful stories in the D world. Guess
 its name? Sociomantic!


I think you might want to do a bit more research into the context and concerns 
behind Don's remarks, before you cite Sociomantic as an argument for keeping 
deprecated features :-)


 Except that porting this subset to its own takes quite some time for
 Sociomantics...


Porting a large codebase, with high performance requirements, through a large 
number of breaking changes, many of which cause silent changes in program 
behaviour ... it's going to take time.  It would be much more straightforward
to 
port a codebase through a sequence of individual, well-defined breaking changes.


 I agree with that. But the point is, D2 has been also reached a state where is
 too much on its plate in terms of contradiction between "be-production-ready!"
 and "be-innovative!". Not even to say "clean up all the dark corners!".


I don't think that well defined, well signposted breaking changes are an issue 
for production code (actually, they are quite welcome if they provide a 
meaningful improvement).  They're more an issue for unmaintained code.


 No, I do not start that discussion. Thing is, you cannot add zillions of flags
 that basically make you jumping from a language to another every time that you
 compile code.


I don't think I or anyone else was suggesting that.
Dec 28 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 28 December 2014 at 22:37:48 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

 On 28/12/14 21:08, eles via Digitalmars-d wrote:

 Thing is, by now, most of D2 code that is written is 
 GC-centric.


 With some exceptions (e.g. embedded programming), the


Yes. And games. And realtime systems (yes, usually embedded). And 
is not only about realtime, it is also about the memory at your 
disposal. But you know that already.

But me, for one, I don't see those as exceptions. That exception 
for you is my full time work. I see only this. "Some exceptions" 
are, for me: desktop applications, client and server 
applications, Web, GUIs etc. Minor stuff that I don't even 
understand why people even write. They are just some minor 
exception.


 assumption of a GC isn't so much a problem as the fact that too 
 many parts of Phobos have been written in a way that doesn't


Yes, yes. As I was telling when rewording what Walter said, there 
is one code style when you write for a GC, and another one when 
you don't. And it support my assertion that most of the D2 code 
written by now is too GC-centric for that to change.

Walter was perfectly right in one of his post when he told: "GC 
must be part of language specifications, because otherwise 
libraries must be written without assuming that a GC is present." 
We're getting there with Phobos. But, I admit, he was visionary.

And I am really worried that throwing the new memory management 
mechanism into the game will not mess things. I thing the 
appropriate way would be "separate build" for that. Read D3.


 allow you to avoid generating garbage (e.g. by passing in 
 preallocated buffers or suchlike).


That is, you design a language that puts the GC at its heart, 
then you fight the compiler and the language to bend it all the 
way to get over its implicit behavior. I really understand why 
people from the C++ world coming here hit the GC thing like a 
wall.


 And you charge this already unstable state with a new 
 mechanism of memory
 management that is yet to be designed, not to say about being 
 written?


 I'm really not sure who this "you" is that you're talking about.


Well. This is why English has two meanings of "you". To make it 
clear.


 I think you might want to do a bit more research into the 
 context and concerns behind Don's remarks, before you cite 
 Sociomantic as an argument for keeping deprecated features :-)


Actually, I was citing his opinion to support the contrary idea: 
clean up the language of deprecated features. They complicate the 
language without giving any help.
Dec 29 2014
next sibling parent "eles" <eles eles.com> writes:
On Monday, 29 December 2014 at 22:49:00 UTC, eles wrote:

 On Sunday, 28 December 2014 at 22:37:48 UTC, Joseph Rushton 
 Wakeling via Digitalmars-d wrote:

 On 28/12/14 21:08, eles via Digitalmars-d wrote:

 Thing is, by now, most of D2 code that is written is 
 GC-centric.







 idea: clean up the language of deprecated features. They


And to this either in a stable build that will be maintained in 
parallel with the crazy (but *the right*) new memory management, 
either do it *before*.

Otherwise will get even more loose.
Dec 29 2014
prev sibling parent "eles" <eles eles.com> writes:
On Monday, 29 December 2014 at 22:49:00 UTC, eles wrote:

 On Sunday, 28 December 2014 at 22:37:48 UTC, Joseph Rushton 
 Wakeling via Digitalmars-d wrote:

 On 28/12/14 21:08, eles via Digitalmars-d wrote:






 then you fight the compiler and the language to bend it all the


And you do that in the language's standard library... Nice basis.
Dec 29 2014
prev sibling parent "eles" <eles eles.com> writes:
On Sunday, 28 December 2014 at 22:37:48 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

 On 28/12/14 21:08, eles via Digitalmars-d wrote:



 Except that porting this subset to its own takes quite some 
 time for
 Sociomantics...


 Porting a large codebase, with high performance requirements, 
 through a large number of breaking changes, many of which cause 
 silent changes in program behaviour ... it's going to take


It was simply ironic. If D1 was a subset of D2, the porting would 
have been immediate: install a D2 compiler and that's all. There 
is no such subset. It looks like one, that's another matter.


 time.  It would be much more straightforward to port a codebase 
 through a sequence of individual, well-defined breaking changes.


And? Isn't that exactly what I was saying? With so much 
featuritis, porting is such a mess that one might better attempt 
a complete rewrite. Why all deprecated and unfinished features if 
they are not even good at porting legacy code?
Dec 29 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/24/14 5:54 AM, Dicebot wrote:

 Only reason why D1 is still used here is huge effort investment to
 actually port that much code without ever delaying normal deployment
 schedule - and I am working on this to change :)


ETA? -- Andrei
Dec 24 2014
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 24 December 2014 at 22:13:26 UTC, Andrei 
Alexandrescu wrote:

 On 12/24/14 5:54 AM, Dicebot wrote:

 Only reason why D1 is still used here is huge effort 
 investment to
 actually port that much code without ever delaying normal 
 deployment
 schedule - and I am working on this to change :)


 ETA? -- Andrei


With current progress I'd estimate second half of 2015 (closer to 
the end) to get first proof of concept service ported to D2. 
Getting completely rid of D1 and specifically ensuring smooth 
transition of services with real-time requirements will take much 
longer, probably several more years.
Dec 24 2014
prev sibling parent reply "newbe" <none none.com> writes:
yes - please resurrect D1!!!!!!!!!!!

+100



On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:

 On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:



 resolution. How about providing it as a separate compiler build


 I feel like dropping D1 was not such a good move. Especially if 
 full ABI compatibility with D2, people could have chose to 
 write some of the less critical modules of their software in D2 
 (along with the enthusiasm of discovery), while still having a 
 stable&non-experimental compiler for the really critical things.

 Then, D1 would have become D1.5 by integrating the D2 
 time-proven features etc., just as D2 could become D2.5.

 Is too late (or undesired) to resurrect D1 in maintenance mode? 
 It is a bit strange that one of the most successful stories of 
 D (Sociomantic) uses D1, still the compiler is ignored and 
 everybody seems pretending that is a D (D2) success story.
Dec 27 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 27 Dec 2014 14:01:50 +0000
newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 yes - please resurrect D1!!!!!!!!!!!
=20
 +100


do you *really* need it? then DO IT.
Dec 27 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 27 December 2014 at 19:18:04 UTC, ketmar via 
Digitalmars-d wrote:

 On Sat, 27 Dec 2014 14:01:50 +0000
 newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 yes - please resurrect D1!!!!!!!!!!!
 
 +100


 do you *really* need it? then DO IT.


Are you willing to help out, ketmar?
Dec 27 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 28 Dec 2014 04:53:51 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Saturday, 27 December 2014 at 19:18:04 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Sat, 27 Dec 2014 14:01:50 +0000
 newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 yes - please resurrect D1!!!!!!!!!!!
=20
 +100


 do you *really* need it? then DO IT.


=20
 Are you willing to help out, ketmar?


i don't need D1, and i'm not interested in D1. so sure, i can help if
the payment will be big enough.
Dec 27 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 28 December 2014 at 05:06:42 UTC, ketmar via 
Digitalmars-d wrote:

 i don't need D1, and i'm not interested in D1. so sure, i can 
 help if the payment will be big enough.


Then your comment makes no sense. If people want trim down and 
refactor D2 then they need to communicate in order to figure out 
if there is common ground. That is, if one wants to break this 
cycle of conglomerate solo-projects.
Dec 27 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 28 Dec 2014 05:11:35 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sunday, 28 December 2014 at 05:06:42 UTC, ketmar via=20
 Digitalmars-d wrote:

 i don't need D1, and i'm not interested in D1. so sure, i can=20
 help if the payment will be big enough.


=20
 Then your comment makes no sense. If people want trim down and=20
 refactor D2 then they need to communicate in order to figure out=20
 if there is common ground.


that's very easy: "hey, guys, i created a site dedicated to D1
resurrection! we have a forum and a wiki, right now we are in the
planning stage. join us and help if you're interested!"

it's easy enough, isn't it? i bet that such message will see a warm
responses. but "yes - please resurrect D1!!!!!!!!!!! +100" is complete
BS. to make something happen just START DOING IT.
Dec 27 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 28 December 2014 at 05:42:07 UTC, ketmar via 
Digitalmars-d wrote:

 BS. to make something happen just START DOING IT.


No, there are way to many projects in the D community that goes 
like that. You need to find common ground, if only 1-2 people 
want it then you cannot sustain it.
Dec 27 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 28 Dec 2014 05:48:45 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sunday, 28 December 2014 at 05:42:07 UTC, ketmar via=20
 Digitalmars-d wrote:

 BS. to make something happen just START DOING IT.


=20
 No, there are way to many projects in the D community that goes=20
 like that. You need to find common ground, if only 1-2 people=20
 want it then you cannot sustain it.


start a site. call for arms. close a site if there will be not enough
tension. writing "yes, resurrect D1!" here will do nothing for the
project: people just have no place to go if they are interested.

but i see that the idea is already deadborn.
Dec 27 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 28 December 2014 at 05:55:02 UTC, ketmar via 
Digitalmars-d wrote:

 start a site. call for arms. close a site if there will be not 
 enough
 tension. writing "yes, resurrect D1!" here will do nothing for 
 the
 project: people just have no place to go if they are interested.


Step 1: figure out what people are unhappy about with D2
Step 2: figure out if there is a reduced feature set that people 
will be happy with
Step 3: figure out how much work it is to refactor D2
Step 4: figure out how many will be interested in contributing
etc...

Wasting time on solo projects that die is not very efficient. 
Spending time on figuring things out is potentially rewarding 
even if one decides to move in a different direction.


 but i see that the idea is already deadborn.


First you need to assess the current state of the D2 compiler to 
see if it is worth the trouble.
Dec 27 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 28 Dec 2014 06:01:39 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sunday, 28 December 2014 at 05:55:02 UTC, ketmar via=20
 Digitalmars-d wrote:

 start a site. call for arms. close a site if there will be not=20
 enough
 tension. writing "yes, resurrect D1!" here will do nothing for=20
 the
 project: people just have no place to go if they are interested.


=20
 Step 1: figure out what people are unhappy about with D2
 Step 2: figure out if there is a reduced feature set that people=20
 will be happy with
 Step 3: figure out how much work it is to refactor D2
 Step 4: figure out how many will be interested in contributing
 etc...


i bet that topic with the name "DIP66 has been approved contingent to a
few amendments as noted" is the best place for this. dedicated forum
can't be better!

besides, there is alot of interest in D1 on D2 NGs!
Dec 27 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 28 December 2014 at 06:10:39 UTC, ketmar via 
Digitalmars-d wrote:

 i bet that topic with the name "DIP66 has been approved 
 contingent to a
 few amendments as noted" is the best place for this. dedicated 
 forum
 can't be better!


That's a different topic. The tail of this thread has been a 
sensible concern about featuritis, and eles expressed a solution 
which someone agreed to. The next step might be to create a 
separate thread, but telling people to create a separate website 
is way out of line.


 besides, there is alot of interest in D1 on D2 NGs!


There are no D1/D2 NGs, only D NG. People are not saying they 
want D1 specifically, they are saying they want a stable D.
Dec 27 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 28 Dec 2014 06:40:08 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 That's a different topic. The tail of this thread has been a=20
 sensible concern about featuritis, and eles expressed a solution=20
 which someone agreed to.


some people reading this in their e-mail clients, and see no "tails",
but a tree. so you actually dropped out such people, as looking for
something in the middle of the discussion tree is... not enjoyable.


 The next step might be to create a=20
 separate thread, but telling people to create a separate website=20
 is way out of line.


there is nothing hard in creating a simple website. i believe that one
can still find a free hosting that either already has or allow to
install some simple wiki and web-forum.


 besides, there is alot of interest in D1 on D2 NGs!


=20
 There are no D1/D2 NGs, only D NG. People are not saying they=20
 want D1 specifically, they are saying they want a stable D.


D1 is dead. dead as a doornail. i don't think that there are alot of
necromancers here. ;-)
Dec 27 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-12-28 05:53, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 Are you willing to help out, ketmar?


If you're interested in D1 you might want to have a look at Amber [1]. 
It's a language based on D1 created by the guys that worked on Tango. 
Differences compared to D1 [2].

[1] https://bitbucket.org/larsivi/amber/wiki/Home
[2] https://bitbucket.org/larsivi/amber/wiki/Diff_D1

-- 
/Jacob Carlborg
Dec 28 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 28 December 2014 at 10:53:30 UTC, Jacob Carlborg wrote:

 On 2014-12-28 05:53, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:


 Are you willing to help out, ketmar?


 If you're interested in D1 you might want to have a look at 
 Amber [1]. It's a language based on D1 created by the guys that 
 worked on Tango. Differences compared to D1 [2].


Yes, except Amber appears to be less mature than D2 according to 
the Amber repository.

https://bitbucket.org/larsivi/amber/wiki/ProgressReport
Dec 28 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/24/14 4:59 AM, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:

 Congratulations, Igor! -- Andrei


 Good to see that.

 It is a big feature though with a notable impact on symbol resolution.
 How about providing it as a separate compiler build for a release or two
 before deploying as part of master?


An emerging pattern (which Walter will effect for dip69) is to initially 
make it opt-in as a flag:

dip -dip69 test.d


Andrei
Dec 24 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei 
Alexandrescu wrote:

 An emerging pattern (which Walter will effect for dip69) is to 
 initially make it opt-in as a flag:

 dip -dip69 test.d


Great!

Though I would suggest -dip=69 as a small tweak for a bit more 
robust CLI (leaves possibility for both -dip=-69 and -dip=+69 in 
future)
Dec 24 2014
parent "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 24 December 2014 at 22:52:12 UTC, Dicebot wrote:

 On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei 
 Alexandrescu wrote:

 An emerging pattern (which Walter will effect for dip69) is to 
 initially make it opt-in as a flag:

 dip -dip69 test.d


 Great!


+1
Dec 25 2014
prev sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei
Alexandrescu wrote:

 On 12/24/14 4:59 AM, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:

 Congratulations, Igor! -- Andrei


 Good to see that.

 It is a big feature though with a notable impact on symbol 
 resolution.
 How about providing it as a separate compiler build for a 
 release or two
 before deploying as part of master?


 An emerging pattern (which Walter will effect for dip69) is to 
 initially make it opt-in as a flag:

 dip -dip69 test.d


 Andrei


Where breaking changes are self-contained in a separate
compilation sense, I'd rather have a pragma that effects the hole
module.

Especially changes that prohibit currently allowed code could be
incorporated bit by bit.
Dec 28 2014
parent "eles" <eles eles.com> writes:
On Sunday, 28 December 2014 at 23:05:28 UTC, Tobias Pankrath 
wrote:

 On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei
 Alexandrescu wrote:

 On 12/24/14 4:59 AM, Dicebot wrote:

 On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei 
 Alexandrescu wrote:







 Where breaking changes are self-contained in a separate
 compilation sense, I'd rather have a pragma that effects the 
 hole
 module.


Much better.
Dec 29 2014
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu 
wrote:

 Congratulations, Igor! -- Andrei


Good news, congratulations Igor.
Dec 25 2014