On Tuesday, 19 July 2016 at 15:22:19 UTC, Andrew Godfrey wrote:
> Just like earlier in this thread, where I mentined dfixable breaking changes and Walter implied that even though a would cause people to have to manually rewrite.

Something being dfix-able is not enough for the simple reason that legacy code in D is already becoming a thing, despite D2 only existing for nine years. A complaint has arisen many times in the forum and in DConfs that there are many packages on code.dlang.org or on Github that don't compile because the author stopped maintaining them. In many cases, these repo's have only been unmaintained for a year(!) or less, and they already don't compile.

There's no way for anyone other than the original author that can fix this; all we can do is add a warning on code.dlang.org. All the while it reduces the signal to noise ratio of good to bad D code online.

Every breakage needs to take into account the baggage of visible old code.

There's also the point that there are few changes which can be dfix-able (according to its author).

On Wednesday, 20 July 2016 at 20:12:14 UTC, Jack Stouffer wrote:
> On Tuesday, 19 July 2016 at 15:22:19 UTC, Andrew Godfrey wrote:
>> [...]
>
> Something being dfix-able is not enough for the simple reason that legacy code in D is already becoming a thing, despite D2 only existing for nine years. A complaint has arisen many times in the forum and in DConfs that there are many packages on code.dlang.org or on Github that don't compile because the author stopped maintaining them. In many cases, these repo's have only been unmaintained for a year(!) or less, and they already don't compile.
>
> [...]

Thanks for the explanation. If most changes aren't dfixable (or aren't believed to be), that explains why the discussions I've read don't mention the dfix approach.

That's an interesting outcome that backward compatibility matters for hobby users more than for commercial users :)

On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote:
> ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it.

It does not need to be planned long in advance, it only requires official backing as a side project. They could freeze current D2 as a stable release and also work on a cleanup.

Instead you get people working on their own forks (myself included), or spin-off languages that goes nowhere.  Because you need momentum.  As a result neither D or the spin-offs gain momentum. And there are several spin-offs (some dead).

In the meantime low level languages like C++, Rust  and semi-high level languages like Swift cuts into the D feature set from both sides. C++ is clogged up by backwards-compatibility issues, but they are also smoothing out the rough edges where D once had clear advantages. Especially in the areas of convenience. C++14/C++17 are not very exciting in terms of features, but the additions are removing what people now seem to call «friction».

In order to stay competitive over time you need something significantly better, like stronger typing, which depends on static analysis, which requires a simple identifiable core (not a simple language, but a simple core language after you remove syntactic sugar).

One possible valuable addition would have been restricted refinement types, another is solid pointer analysis (without false positives).

Neither are incompatible with D as such, but you would probably need to attract compiler developers with a theoretical background to get it up in reasonable time. Without a clean core they will conclude that the it will be too much work and they will go to other big languages instead or work on other alternative languages that also go nowhere because they lack momentum...

On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad wrote:
> Not sure what you mean.
>
> 1. It is more time consuming to write an analysis engine that can cover convoluted machinery than simple machinery.
>
> 2. It it more difficult to extend complex machinery than simple machinery.
>
> 3. It is more work to figure out adequate simple machinery to describe complex machinery, than just keeping things simple from the start.
>
> Not very surprising that experienced language designers try to keep the core language as simple as possible?

You can lower D to Assembler and analyze that. Assembler is simple, isn't it?

On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote:
> On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad wrote:
>> Not sure what you mean.
>>
>> 1. It is more time consuming to write an analysis engine that can cover convoluted machinery than simple machinery.
>>
>> 2. It it more difficult to extend complex machinery than simple machinery.
>>
>> 3. It is more work to figure out adequate simple machinery to describe complex machinery, than just keeping things simple from the start.
>>
>> Not very surprising that experienced language designers try to keep the core language as simple as possible?
>
> You can lower D to Assembler and analyze that. Assembler is simple, isn't it?

Are you trolling? Lowering discards information.

On Thursday, 21 July 2016 at 08:40:03 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote:
>> ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it.
>
> It does not need to be planned long in advance, it only requires official backing as a side project. They could freeze current D2 as a stable release and also work on a cleanup.
>
> Instead you get people working on their own forks (myself included), or spin-off languages that goes nowhere.  Because you need momentum.  As a result neither D or the spin-offs gain momentum. And there are several spin-offs (some dead).

You seem to be assuming that everyone already agrees on which set of changes should be made to the language. (Otherwise, how could you expect anyone to "officially back" a side project?)

But agreeing on which changes to make and, especially, which to NOT make, is the hard part. And it's why you'd need a lot of planning & discussion up front (if any of us non-founders wanted to participate). And many people don't understand this, which IMO is behind a lot of hard feelings in the forums.

On Thursday, 21 July 2016 at 16:21:17 UTC, Andrew Godfrey wrote:
>> You can lower D to Assembler and analyze that. Assembler is simple, isn't it?
>
> Are you trolling? Lowering discards information.

AFAIK, that's what static analysis is built for: to infer high-level properties of the code that are not expressed in it.

On 07/18/2016 03:37 PM, Walter Bright via Digitalmars-d wrote:
> On 7/18/2016 6:48 AM, Andrew Godfrey wrote:
>> We risk scaring away potential community members, and alienating existing ones,
>> by the way we say "no" to proposals for breaking changes. We could improve how
>> we say "no", by having a place to point people to. Potential topics:
>
> Anything we do will risk scaring away people. The only answer is we have to do what is right.
>
>
>> 3) Why we feel that breaking changes risk killing D outright. (I just don't see
>> it. I wonder if we're confusing "dfixable" breaking changes, with other more
>> disruptive kinds (such as Tango=>Phobos).)
>
> Because if you thoroughly break a person's code, you put them in a position of rewriting it, and they may not choose to rewrite it in D3. They may choose a more stable language.
>
> I have many older programs in different languages. It's nice if they recompile and work. It's not nice if I have to go figure out how they work again so I can get them to work again.
>
For some changes there could be switches, rather like optimization level switches, or those managed by version.  This would allow the compilation version to be set based on a compile time variable,  I'm not totally sure whether this should be file level or, as with version, block level...or selectable.  This would get to be a huge maintenance chore after awhile, but it would allow you a few years to deprecate code.

The question is "How important would a change need to be to justify this kind of action?", and my guess is that it would need to be pretty important.

On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote:
> You can lower D to Assembler and analyze that. Assembler is simple, isn't it?

You can, and that is what C++ is mostly limited to, but you then you most likely get false positives and cannot use the analysis as part of the type-system. If you are going to use e.g. pointer analysis as part of the type system, then it has to happen at a higher level.