On Thursday, 13 March 2014 at 11:14:56 UTC, Suliman wrote:
> A lot of people here are talking about C. They are saying that C almost do not have changes that had break compatibility and it's good. But people are forgot, that D is much more complex language then C is.
>
> Look at C#, it's had a lot of changes and it's become from stupid clone of Java very powerful and modern language.
>
> But also look at Python. Pythons are afraid about backward compatibility for a long time and as result we have 2 incompatibility version 2.x and 3.x. And 3.x version was released 6 years ago (!).
>
> I understand that people do not like to fixing code, but it's better to fix most important things now, than to get pain in the future.
>
> IMHO.

+1

Great example is how in Python 3.x that pyglet which is highly used for 3d games isn't really fully ported there. Although it does work, mostly.
Or another example how PIL (Python Image Library) isn't ported in any form to 3.x yet. In some ways Python is in a worse position than D is for image libraries. Which is kinda scary.

But in saying this its bound to happen when there is money to keep another major version updated.

>    !final
>    !pure
>    !nothrow
>    etc.

As an alternative: how about using a syntax similar to noexcept in C++11?
http://en.cppreference.com/w/cpp/language/noexcept
That would result in final(true) and final(false).
Same for pure etc.

On Thursday, 13 March 2014 at 10:19:09 UTC, Andrej Mitrovic wrote:
> On 3/13/14, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> Those who wish to represent themselves should represent themselves.
>
> Another important point to make: If client A says a specific changeset
> was bad, what gives client A priority over client B who says the same
> changeset is good? These clients need to  communicate directly with
> the community and the developers via the forums and by filing
> bugs/enhancement reports.
>
> I believe clients (why are we calling them "clients" anyway?) should
> have to provide reasonable arguments for preferring one feature over
> another, beyond the simple "we're using D therefore we're important"
> argument.

What forcing those people to reconsider their decision to use D if the changes become an hassle?

For example, I do talk a lot here, because not only I do like D and its community but also am a language geek at heart.

On my day job there is no chance I could ever use D, as we only do JVM/.NET/Mobile consultancy, the last C++ boat sailed around 2006.

Sometimes I do advocate D though, but those people won't jump into a language they cannot consider stable enough.

--
Paulo

"Don"  wrote in message news:ekymfpqyxasvelcixrjp@forum.dlang.org...

> I agree completely.
>
> Some things that really should be fixed, don't get fixed because of a paranoid fear of breaking code. And this tends to happen with the issues that can give nice warning messages and are easy to fix...
>
> Yet there are still enough bugs that your code breaks every release anyway.
> We need to lose the fantasy that there is legacy code which still compiles.
> Anything more than a year or so old is broken already.

As usual I agree with every single thing in this post, and Sean's. Regressions are bad but have nothing to do with using slow, controlled deprecation to make the language better. 

On Thursday, 13 March 2014 at 10:19:09 UTC, Andrej Mitrovic wrote:
> Another important point to make: If client A says a specific changeset
> was bad, what gives client A priority over client B who says the same
> changeset is good? These clients need to  communicate directly with
> the community and the developers via the forums and by filing
> bugs/enhancement reports.
>
> I believe clients (why are we calling them "clients" anyway?) should
> have to provide reasonable arguments for preferring one feature over
> another, beyond the simple "we're using D therefore we're important"
> argument.

Just to be clear, I never had a "preferred" implementation, nor I would ever "lobby" for one as it's not in the best interest of anybody.
Consider me a fan of breaking the code if it improves features, security and what not.
The only thing I'm asking for is for it to be transparent: a point in the changelog and keeping the old one as deprecated for a reasonable amount of time, that's all.

A bug was not filed as it didn't look like a bug but a design choice (undocumented).
If reporting it directly to Walter Bright was the wrong thing to do, my apologies, but we surely didn't have any hidden "agenda" here.

Thanks
Daniele

Dne 13.3.2014 12:07, Jonathan M Davis napsal(a):
> really going to help much. There may ultimately still be some value in them,
> but most people who suggest this sort of solution seem to be under the
> impression that it would somehow stop accidental code breakage, and that isn't

The point of long-term stable release is not that no bugs ever can be introduced. The point is that there are fewer changes and no language and library changes which force the user to update his source code are introduced (accept-invalid aside, maybe).

Currently users have to choice either:

- stick with some old release with no bugfixes at all
- always upgrade to the latest release, which mixes bugfixes, language and library changes.

What if user want just regressions and (some) major bugs fixed ?

Also long-term stable release would make a base against which deprecations can be marked.

-- 
mk

On Thu, 13 Mar 2014 04:43:51 -0400, Don <x@nospam.com> wrote:

> On Thursday, 13 March 2014 at 06:02:27 UTC, Walter Bright wrote:
>> On 3/12/2014 9:23 PM, Manu wrote:
>>> It's not minor, and it's not achievable by other means though.
>>
>>     class C { final: ... }
>>
>> does it.
>>
>>
>>> You and Andrei are the only resistance in this thread so far. Why don't you ask
>>> 'temperamental client' what their opinion is? Give them a heads up, perhaps
>>> they'll be more reasonable than you anticipate?
>>
>> I didn't even know about this client before the breakage. D has a lot of users who we don't know about.
>>
>>> Both myself and Don have stated on behalf of industrial clients that we embrace
>>> breaking changes that move the language forward, or correct clearly identifiable
>>> mistakes.
>>
>> Breaking changes has been a huge barrier to Don's company being able to move from D1 to D2. I still support D1 specifically for Don's company.
>
> Yes, but the problem is not the changes which cause compile errors and force you to change your code in obvious ways. The problem is subtle changes to behaviour.
>
> The worst breaking change in D2, by far, is the prevention of array stomping.
>
> After that change, our code still runs, and produces exactly the same results, but it is so slow that it's completely unusable. This one of the main reasons we're still using D1.

What is your use case(s), might I ask? Prevention of array stomping, I thought, had a net positive effect on performance, because it no longer has to lock the GC for thread-local appends.

-Steve

On 3/13/14, Daniele Vian <dontreply@example.com> wrote:
> The only thing I'm asking for is for it to be transparent: a point in the changelog and keeping the old one as deprecated for a reasonable amount of time, that's all.

Yeah, that's what we're always trying to do. If something broke but wasn't mentioned in the documentation, please do file a bug. Thanks.

> If reporting it directly to Walter Bright was the wrong thing to do, my apologies, but we surely didn't have any hidden "agenda" here.

Walter made it sound as if you were wiling to stop using D because of a single regression.

It's maybe not proper topic but maybe someone disagreed with current way of D may interesting to continue Amber project. https://bitbucket.org/larsivi/amber/commits/all

"Daniele Vian"  wrote in message news:qggzguvbwtpaipdmnsgq@forum.dlang.org...

> Just to be clear, I never had a "preferred" implementation, nor I would ever "lobby" for one as it's not in the best interest of anybody.
> Consider me a fan of breaking the code if it improves features, security and what not.
> The only thing I'm asking for is for it to be transparent: a point in the changelog and keeping the old one as deprecated for a reasonable amount of time, that's all.

I think we can all agree on that.

> A bug was not filed as it didn't look like a bug but a design choice (undocumented).

If it breaks your code without warning, it's usually worth filing a bug. Bugzilla is the best place to report possible regressions, as all the relevant people are paying attention.  Worst case it gets closed with an explanation of why it was changed.

> If reporting it directly to Walter Bright was the wrong thing to do, my apologies, but we surely didn't have any hidden "agenda" here.

There is nothing wrong with reporting directly to Walter, the problem is when Walter/Andrei then make decisions based on this information privately. Walter has been wrong about these things in the past, and without knowing who the third party is it's impossible to get clarification.