On 10/12/2014 2:14 PM, Sean Kelly wrote:
> 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.

It turns out that a lot of them can be bent straight if put in a structure in the right way. For example, triangular bracing can pull them in line. The more warped ones can be used for shorter sections. It's all about compensating for the imperfections, and a good carpenter can do that.


> 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.

No doubt. People like salvaged wood so much they'll beat a brand new wood floor with chains. And, of course, people buy brand new jeans that are beaten with stones and deliberately ripped up.

>> 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.

The main counterargument against this change is that it's yet another change that require people to rewrite their code.
Also the pull simply deprecates certain code, but for good acceptance we also need to educate D users why we're doing this change and must make updating code as painless as possible. A tool like dfix will become more important with every line of D code that is written. Too often we're only looking at phobos.

> it's for a practice that we've already been discouraging for some time now

Never heard of it before. If this were common knowledge, as in every D beginner would stumble over that information, it would solve half of the problem.
I'd still welcome if someone updated the style guide.

> 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,

Obviously we should fix all of our own code and explain people why they should update theirs before we start deprecating it.

On 09/10/14 17:32, francesco cattoglio wrote:
> On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
>> Kenji just proposed a slightly controversial pull request so I want to
>> reach out for more people to discuss it's tradeoffs.
>> It's about deprecating function qualifiers on the left hand side of a
>> function.
> I'm all for it
>
>> Then at some future point we could apply the left hand side qualifiers
>> to the return type, e.g. `const int foo();` == `const(int) foo();`
> I know it's not happening anytime soon, but I'm against this second
> idea. This will be an extra annoyance when "porting" old D code to a new
> version. Just removing the currently ambiguous attribute on the left
> should be plenty. No need to try to mimic C in this regard.

+1

On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote:
> I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos...

No.

I actually think it's a very good thing that it's possible to preserve old, obsolete modules in Phobos.  As long as everything is covered in a strict deprecation warning to let everyone understand it is obsolete, it's better to keep the code there for backwards compatibility than gratuitously remove it, because of the risks of breakage to old codebases.

For the same reason, I'm happy to see LHS attributes be deprecated, but not for support for them to be removed.

On Monday, 13 October 2014 at 15:58:05 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote:
>> I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos...

 Yes, you are right. Mea culpa, I misinterpreted.

 OTOH, there is some cleaning needed, I think, complex types being prime example.

On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:
> Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.

Indeed, but the choice of _when_ to remove can in practice be quite free, no?  It would be possible to put in place this deprecation warning and wait for years before acting on it.

On Sunday, 12 October 2014 at 11:24:17 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> 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.

I used to think that this was a valid point w.r.t. rejecting changes. Over the last year of actually trying to get work done in D, I've changed my tune somewhat:

At this stage, almost every release will break any project that has a decent sized code-base, *without considering any language changes or regressions*!

Fixing *any* rejects-valid or accepts-invalid bug can break peoples code.[1]
Adding a new symbol in phobos can break peoples code.

The only way of getting meaningful stability is to slow down a lot. If we're going to keep moving fast (even just fixing bugs), then it is unavoidable that we will break people's code. We can afford a little more breakage on top of the inevitable (and undeniably necessary) pile - even for quite minor gains - as long as they are changes that can be easily managed by project maintainers.[2]


The only argument that's left is: "I don't mind you breaking my code by fixing bugs in the implementation, but I do mind when it's for cleaning/changing the language/phobos". In light of recent comments from heavyweight users saying "please break my code in the name of improving the language and libraries", I don't think it holds much water.

[1] The "code that was already broken" is often dodgy. What constitutes broken code? There's a lot of very fragile code out there that is doing it's job just fine, in the limited circumstances it's used.

[2] By easily managed I don't mean sed-able, or even tooling-fixable. For me it pivots on being able to maintain one code-base that will compile with multiple compiler versions. An example where this fails: @nogc, being an attribute, isn't aliasable, meaning you can't version it out neatly.

#PleaseBreakMyCode but also #PleaseProvideScalableMeansForMeToProvideBackwardsCompatabilityToMyUsersWhoBuildMyCodeOnAVarietyOfSystemsWithAVarietyOfCompilers    Hmm, not so catchy :)

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.
>

No. Let me explain. In
qualifier(type) identifier();
qualifier apply to type. This is all good, as expected.

In
attribute type identifier();

attribute apply to identifier. identifier is a function here, and
it make sense to apply pure on a function.

The problem with type qualifier on a function, is that they do
not make any sense. For some reason, a type qualifier used on a
function will qualify the implicit parameter.

It is confusing the hell out of everybody as there is a thing on
which is make sense to apply the qualifier to (the return type)
and a thing where it does not make sense (the function) but for
some reason, when you apply it on the function it has a "magic"
meaning. That is the surprise effect.

On Sunday, 12 October 2014 at 21:51:33 UTC, Jonathan M Davis via
Digitalmars-d wrote:
> 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

The right path forward seems to be deprecating now, but not
removing before dfix can do something good about it.

On Sunday, 12 October 2014 at 23:25:57 UTC, Martin Nowak wrote:
>>> 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.
>
> The main counterargument against this change is that it's yet another change that require people to rewrite their code.
> Also the pull simply deprecates certain code, but for good acceptance we also need to educate D users why we're doing this change and must make updating code as painless as possible. A tool like dfix will become more important with every line of D code that is written. Too often we're only looking at phobos.
>

I'm sorry, but that won't cut it. People have been asking for
this change since like forever. This whole problem could be gone
by now, and at the time there was no release that won't make you
rewrite your code anyway.

No it is like, "we didn't made the change at the time for bad
reason, and now we don't want to make the change because we made
a bad decision at the time and change is more costly now".