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.

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.

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?

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.