On 11/10/14 06:11, Dicebot via Digitalmars-d wrote:
> Reddit users are not the ones who invest into this language. If this attitude
> won't change it is only a matter of time until you start losing existing
> corporate users deciding to go with other language or a fork instead (likely
> latter).
>
> ...
>
> #pleasebreakourcode

You propose ignoring Teh Internetz and try to enlist a Twitter hashtag to that end? ;-)


> Consistency and being robust in preventing programmer mistakes is single most
> important feature in the long term. @nogc, C++ support, any declared feature
> - it all means nothing with a simple necessity to not waste money fighting
> the language.
>
> ...
>
> Hardly anything matters more than that. Issues like that consume our time
> continiously for years, accumulating in wasted days weeks of worker time.
> Compared with time needed to adjust even several MLOC project gain is clear.

I don't think this message can be over-emphasized enough.  By far the major difficulty of programming effectively (in any circumstances, but particularly in a corporate environment) is having to deal with quirks and special cases in a language and its libraries where "the right thing" and "the obvious thing" diverge.

Such quirks don't just lead to more frequent programmer error, they also lead to uglier and less easily maintained codebases, which almost always has a multiplicative effect in terms of the overall quirkiness the developer has to deal with.  It's a LOT of lost time.

By contrast, when a language and/or library successfully conflates "the easy thing" and "the right thing", the effect is multiplicative in the other direction -- as a programmer, it helps you learn and implement good design patterns that carry all the way up the software stack.  I'm firmly of the belief that D's successes in this respect not only made it easier for me to program, they made me a better programmer.

D2 is, for the most part, excellent in this respect, but it could and should be even better.  Well-managed, well-documented and well-publicized breaking changes in support of usability and correctness are desirable, not something to be avoided.

On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d wrote:
> D2 is, for the most part, excellent in this respect, but it could and should be
> even better.  Well-managed, well-documented and well-publicized breaking changes
> in support of usability and correctness are desirable, not something to be avoided.

I should add here -- I recognize the basic problem that faces any language when you have newcomers (or potential corporate adopters) downloading the latest compiler, downloading some codebase of interest to them, and finding that it doesn't build because of a backwards-incompatible change.  Even when that change was 100% justified, you risk being seen as unstable, untrustworthy, etc., and many people are not patient enough to stick around to hear that justification.

Now, that said, I think it's helpful to try and change the conversation from, "Break/don't break" to, "What would be the circumstances under which it could be feasible to make these desirable breaking changes?"

The original version of this email had some thoughts on that, but to be honest, I'd rather just ask the question, without making any assumptions about what the answer could or should be.

On 10/11/2014 11:17 PM, Dicebot wrote:
> On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote:
>> On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:
>>> On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:
>>>>> Wait what? Are you saying there is a single case when this:
>>>>>
>>>>> const T var;
>>>>>
>>>>> is not identical to this:
>>>>>
>>>>> const(T) var;
>>>>
>>>> No, look at the pointer symbol.
>>>
>>> module test;
>>>
>>> const int**  a;
>>> const(int**) b;
>>
>> The original code you quoted was "const(T)* v;" where the "*" was
>> *outside* of the parens.
>
> There was no * in my quote, only `const(T)` vs `const T` (with any
> compound T)
>
> The fact that const T* means const(T*) does not indicate that const is a
> storage class but simply a parsing rule. Walter has made a statement
> that there is a const storage class that is distinct from const
> qualified. I want example.

As far as I understand, this is a compiler implementation detail.

On Sunday, 12 October 2014 at 09:29:08 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:
>> On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>>> I agree with that general sentiment, but doesn't this patch only deprecate
>>> left-hand-side function attributes?
>>
>> Only some of them, others remain:
>>
>>     pure int foo() { ... }
>
> Not good.  If LHS function attributes are to be deprecated, it really ought to be all or nothing.

Not necessarily. `pure` is a real function attribute, while `const` applies to the implicit `this` paramater and _not_ to the function.

On 10/12/2014 2:28 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>> Deprecation means it'll be removed.
>
> Hmm, maybe I've misunderstood the deprecation process.  It was my understanding
> that, to remove a feature or function, it was necessary to deprecate it first;
> but that deprecation would not necessarily always lead to deletion.
>
> I may be thinking too specifically of Phobos, where it's obviously much easier
> to deprecate a module without ever removing it.

Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.

On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:
> On 10/12/2014 2:28 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>>> Deprecation means it'll be removed.
>>
>> Hmm, maybe I've misunderstood the deprecation process.  It was my understanding
>> that, to remove a feature or function, it was necessary to deprecate it first;
>> but that deprecation would not necessarily always lead to deletion.
>>
>> I may be thinking too specifically of Phobos, where it's obviously much easier
>> to deprecate a module without ever removing it.
>
> Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.

I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos...

On 10/10/2014 4:04 PM, Brad Anderson wrote:
> I think it's rather unfortunate that D used keywords from C++ for things that
> work differently. const in particular but struct and class cause confusion and
> bickering too. Think of all the hours spent on this newsgroup arguing about
> logical const. If D's const were called something else like readonly nobody
> would be trying to shoehorn logical const into it and calls for logical const
> would have been discussed without having to pit two features against each other
> for a single spot in the language.

These kinds of problems always occur when transitioning from one language to another. I'm not trying to be dismissive, but I feel that a language has to pick its battles.

BTW, C++ const constantly causes confusion even for experienced C++ programmers.


> Another is char for utf-8 code units. So many people assume a char is a
> character when it's actually only sometimes a character by coincidence. If it
> had a different name like utf8_unit people would probably write more unicode
> correct code naturally.

C++ has the same problem, only far worse, since char is used for all kinds of multibyte characters, and most legacy/library code assumes ASCII. Java has the same issue (surrogate pairs).

There are other issues:

1. integers overflow
2. floating point numbers have precision problems

Programming languages are always imperfect models, it's like the 2x4's you buy at the hardware store are never straight. You just learn to deal with it, because perfectly straight ones would be prohibitively expensive.

On Sunday, 12 October 2014 at 19:40:56 UTC, Walter Bright wrote:
>
> Programming languages are always imperfect models, it's like the 2x4's you buy at the hardware store are never straight. You just learn to deal with it, because perfectly straight ones would be prohibitively expensive.

Well... some of them are straight.  If you're building something that's built from near full-length boards then you search for the straight ones.  Otherwise you just take whatever.  In fact, the last time I was sifting through 2x4s at Home Depot, one of the people working there asked me to set the warped ones aside so they could take them out.  I'm sure they chip them and make press-board or whatever out of them instead.

The other tricky thing about selecting 2x4s is that once you get to the center of the palette the boards tend to be damp, and so there's a chance that they'll be straight when you buy them but they'll warp as they dry.  There's kind of an art to selecting wood for a building project.

So I guess the point is that you use the proper materials for the job.  With physical jobs, the leftovers can almost always be repurposed or remade into something suitable for a different job.  So there's very little actual waste.  Competent builders can even use salvaged materials to create an entirely new thing.  I have a set of record shelves that are built from salvaged deck beams.  Aged wood tends to be really beautiful because colors and textures emerge as it ages.

What I've learned about building is that, just like programming, there's an established process for everything.  And building new structures is largely a matter of assembling the pieces and joining them in the proscribed manner.  So you quickly start thinking about projects in terms of the larger problem rather than the complexity of constructing an individual wall section or whatever.

> This has been being brought up for years. I wouldn't expect 6 months to change
> anything. If we want to delay it until dmd's headergen and ddoc are fixed and
> put a note in the changelog on the next release that it's going to be
> deprecated rather than deprecating it immediately, we can do that, but I don't
> think for a second that the arguments are going to change.

Automatic code rewriting is what might make syntax deprecations more feasible in 6 month.

On Sunday, October 12, 2014 21:17:29 Martin Nowak via Digitalmars-d wrote:
> > This has been being brought up for years. I wouldn't expect 6
> > months to change
> > anything. If we want to delay it until dmd's headergen and ddoc
> > are fixed and
> > put a note in the changelog on the next release that it's going
> > to be
> > deprecated rather than deprecating it immediately, we can do
> > that, but I don't
> > think for a second that the arguments are going to change.
>
> Automatic code rewriting is what might make syntax deprecations more feasible in 6 month.

Perhaps, but this change is so straightforward that I would expect that even a very large codebase could be updated in a very short space of time. And since it'll be generating deprecation messages - not errors - and it's for a practice that we've already been discouraging for some time now, I don't think that waiting for dfix buys us much. I totally agree that it would be nice to have, but I don't see it as a showstopper at all. The only significant problem I see is dmd's headergen, because if that's putting const on the left, then it'll generate code that will then be warned about, which would definitely be bad. The ddoc generation should be fixed to, but that can be done later, because the semantics won't have changed; it's just that if you do it in your own code, you'll get a deprecation message.

I'd very much like to see this change made sooner rather than later. I think that it continues to harm us as long as it isn't changed, and the change really doesn't cost much even if your whole codebase needs to be updated, because it's very simple and straightforward.

- Jonathan M Davis