[Issue 12931] Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WONTFIX --- Comment #22 from Mathias LANG --- So after raising a PR, it turns out Walter is against it: https://github.com/dlang/dmd/pull/10757#issuecomment-586849786 Marking as "WONTFIX" as a result. Feel free to chime in on Github if you feel strongly about it. --
[Issue 12931] Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 --- Comment #21 from Dlang Bot --- dlang/phobos pull request #7389 "[Trivial] Issue 12931: Move shared to the RHS" was merged into master: - 3140fb9e3aa2b6b6eabc1ce718cc88f8830d36d5 by Geod24: Issue 12931: Move shared to the RHS https://github.com/dlang/phobos/pull/7389 --
[Issue 12931] Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 --- Comment #20 from Dlang Bot --- @Geod24 created dlang/dmd pull request #10757 "Fix issue 12931: Make ambiguous qualifiers illegal on the LHS of a function" fixing this issue: - Fix issue 12931: Make ambiguous qualifiers illegal on the LHS of a function This has been a pain point for many D users for years, both new and old, as can be seen from the discussions on the issue. It is however a potentially disruptive deprecation. Note: The test for issue 5962 in test/runnable/xtest46.d has been removed as the issue was only present with prefix syntax. https://github.com/dlang/dmd/pull/10757 --
[Issue 12931] Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 --- Comment #19 from Dlang Bot --- @Geod24 created dlang/phobos pull request #7389 "[Trivial] Issue 12931: Move shared to the RHS" mentioning this issue: - Issue 12931: Move shared to the RHS https://github.com/dlang/phobos/pull/7389 --
[Issue 12931] Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 --- Comment #18 from Mathias LANG --- *** Issue 12930 has been marked as a duplicate of this issue. *** --
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sun, 19 Oct 2014 10:06:31 +0100, eles eles...@gzk.dot wrote: On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote: On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak c...@dawg.eu wrote: Would this affect your code? Probably, but I have no D code of any size to care about. Would this change make you to write more code in D? No. The blockers for me are: 1- We're not likely to use D here at work any time soon. We're writing new stuff in C#/Java and we maintain legacy C/C++. 2- For my own projects I typically write windows GUI programs and D is no where near C# for this. 3- Last time I tried to write anything non-GUI of a substantial nature I was annoyed by the fact that I could not mixin virtual methods (which I know is a tough problem and waaay down the priority list if at all). It's a silly reason to be put off, I know, it was just disappointing and enough to put the brakes on and I just drifted off after that. 4- TBH I don't have enough free time or motivation to do more, it's not you (D) it's me :P R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote: On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak c...@dawg.eu wrote: Would this affect your code? Probably, but I have no D code of any size to care about. Would this change make you to write more code in D?
[Issue 12931] Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #17 from Martin Nowak c...@dawg.eu --- Just had to fix openssl bindings. https://github.com/MartinNowak/openssl/commit/b3a334b5bcea8afc7a68573d4363891e7e0bc422 Translating const EVP_CIPHER *EVP_rc4_hmac_md5(void); to const EVP_CIPHER *EVP_rc4_hmac_md5(); instead of const(EVP_CIPHER)* EVP_rc4_hmac_md5(); It's a common mistake during C header translation. Since 2.066.0 the compiler at least warns that const can only be applied to member functions. --
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote: On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak c...@dawg.eu wrote: Would this affect your code? No Do you think it makes your code better or worse? Better. More clear Is this just a pointless style change? No
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 13:47:55 +0100, Martin Nowak code+news.digitalm...@dawg.eu wrote: https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now. +1 -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak c...@dawg.eu wrote: Would this affect your code? Probably, but I have no D code of any size to care about. Do you think it makes your code better or worse? Better. Is this just a pointless style change? Nope. Anything else? Only what you said in summary to this thread (I am waay late to this party) Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
Jonathan M Davis via Digitalmars-d wrote in message news:mailman.768.1413233509.9932.digitalmar...@puremagic.com... I don't know that we need to wait for dfix, but we never remove deprecated stuff from the language very quickly anyway. So, I expect that it'll be around for at least a year or two before we look at actually removing it, so dfix will presumably be able to take care of it long before we're looking to remove it anyway. And even without dfix, non-trivial year-old code rarely compiles with the latest frontend.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
John Colvin wrote in message news:ljjtmnnckwzenvhaw...@forum.dlang.org... [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. There is nothing stopping you from not supporting @nogc until your oldest supported dmd version has it. I agree with your requirement, but this is not a good example of it. A better example would be requiring nothrow annotations on inline asm blocks, because the old code won't compile with newer dmds and the new code won't compile with older ones.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Tuesday, 14 October 2014 at 16:11:34 UTC, Daniel Murphy wrote: John Colvin wrote in message news:ljjtmnnckwzenvhaw...@forum.dlang.org... [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. There is nothing stopping you from not supporting @nogc until your oldest supported dmd version has it. Good point. It would be nice to be able to take advantage of new features though, whilst maintaining backward compatibility. Also, a 3rd party project could make @nogc a requirement, meaning I have to choose between compatibility with older compilers or with that 3rd party code. Alias-able attributes would help a lot. I agree with your requirement, but this is not a good example of it. A better example would be requiring nothrow annotations on inline asm blocks, because the old code won't compile with newer dmds and the new code won't compile with older ones. Yes, that's a more concrete example, thanks.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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 :)
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Monday, 13 October 2014 at 16:00:21 UTC, Joseph Rushton Wakeling wrote: 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. This is one thing I'd love major versions to be used for. Deprecate bunch of things iteratively, remove them completely in D 3.xx.yy ; aggregate bunch of new deprecated things and release D 4.xx.yy etc.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Monday, October 13, 2014 19:59:13 deadalnix via Digitalmars-d wrote: The right path forward seems to be deprecating now, but not removing before dfix can do something good about it. I don't know that we need to wait for dfix, but we never remove deprecated stuff from the language very quickly anyway. So, I expect that it'll be around for at least a year or two before we look at actually removing it, so dfix will presumably be able to take care of it long before we're looking to remove it anyway. - Jonathan M Davis
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Monday, 13 October 2014 at 17:15:34 UTC, John Colvin wrote: 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. Well, in this case we don't necessarily need to break anyone's code, it would be possible to stop at deprecation. But generally speaking, I agree with you, which is why I was hoping to move the debate to, What are the circumstances under which these breaks are possible, rather than Should we/shouldn't we.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
I don't particularly mind you refusing it, but deprecation (in support of good
stylistic practice) isn't breaking.
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a 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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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...
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote: This has come up before, and has been debated at length. const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v In particular, const T *v; does not mean: const(T)* v; 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. 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). I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it. 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. In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer. This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) 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. Agreed with the sentiment. #pleasebreakourcode Lol.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright 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). Sadly, +1 I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it. 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. In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer. This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) 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. #pleasebreakourcode +1 over all Plus, I would not spend anymore one world in arguing against the reddit argumentation: it's really too much for me. --- /Paolo
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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() { ... }
I don't particularly mind you refusing it, but deprecation (in support of good
stylistic practice) isn't breaking.
Deprecation means it'll be removed.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: #pleasebreakourcode No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 10:18:29 UTC, bachmeier wrote: On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: #pleasebreakourcode No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code. It does not sound as catchy :P Though I agree in statement itself
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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; **a = 42; Error: cannot modify const expression **a B _D4test1axPPi 0008 B _D4test1bxPPi ??? Can you give an examle of the code that actually observes the semantical difference?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 14:47:55 +0200 Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: Then we might revisit the topic in 6 month and see whether we have better arguments now. six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they? signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 12:48:03 UTC, Martin Nowak wrote: https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now. Sounds good but what is the benefit over just having deprecation period 6 months longer?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 14:47:55 +0200 Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: Then we might revisit the topic in 6 month and see whether we have better arguments now. six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they? gtfo ketmar
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 15:17:36 UTC, ketmar gtfo wrote: On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 14:47:55 +0200 Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: Then we might revisit the topic in 6 month and see whether we have better arguments now. six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they? gtfo ketmar gtfo ketmar gtfo
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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. **a = 42; Error: cannot modify const expression **a B _D4test1axPPi 0008 B _D4test1bxPPi ??? Can you give an examle of the code that actually observes the semantical difference? I cannot. I was trying to prove that there isn't, after you made the statement Wait what? Are you saying there is a single case when this is not identical to this.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, October 11, 2014 14:47:55 Martin Nowak via Digitalmars-d wrote: https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-5874835 3 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now. 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. Many of us have been complaining about this for years, and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it is (which I strongly dispute). As far as I can tell, Walter is the only real obstacle to this. Almost no one else ever seems to think that having const function modifiers on the left is a good idea. And now that someone has finally implemented the change, I really think that we need to get it merged. Honestly, I think that delaying making the change just increases how much harm the problem is causing, because it's around that much longer, confusing that many more folks. As far as popular opinion goes, it's quite clear that almost everyone posting here thinks that it should be changed. The only one who seems to really need to be convinced is Walter, and apparently, no one knows how to do that. I can see delaying making the changes until the dmd headergen is fixed being needed so that the compiler isn't generating code that it then prints a deprecation message for, and it would be nice if the ddoc generation were fixed ASAP as well, but if that's the case, I think that that just means that those should be fixed ASAP so that const function qualifiers on the left can be deprecated ASAP. I see no need to continue to discuss whether we should do this beyond someone miraculously coming up with a way to convince Walter. - Jonathan M Davis
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
Jonathan M Davis: and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it is Consistency is a good thing to have, but if adhering to it causes bugs and troubles, and if the symmetry breakage causes readable compile-time errors, then it's often a good idea to do it. D language contains plenty of situations where this happens (and arguably few more cases should be added, like the sbyte/ubyte pair of names breaking the consistency of name/uname naming scheme for the other integral types, to avoid people think all the time that a byte is unsigned). Bye, bearophile
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 22:41:50 + bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Jonathan M Davis: and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it is Consistency is a good thing to have and it's not a goal, it's just a nice way to say i don't want this. see @safe, @trusted, pure and nothrow, for example. i can hardly say that it's consistent. breaking consistency rising up only if there is nothing else to say against something. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/11/2014 3:18 AM, bachmeier via Digitalmars-d wrote: On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: #pleasebreakourcode No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code. Yes, there will be. That there's a period of transition helps reduce it, but to believe that all code everywhere is upgraded during that transition is... wishful thinking. That said, I'm still in favor of this change. Please, remove the human confusion, there's enough of it already and this one is easy to fix.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
For functions, const-as-storage-class applies to the function
symbol. And if it is misused, the compiler will very likely
complain about a mismatched type.
Breaking this adds a special case inconsistency, besides
breaking existing code.
Come on that is the same bogus reason every time. const here do
not apply to the function but to its hidden, implicit parameter.
And that is actually a problem.
const void delegate() dg; // dg should be const, and there is no
way to qualify the implicit parameter.
You obviously can't pretend you don't know this as:
const int foo() {}
Gives you an error because you have no this pointer to make
const. So let's not pretend that this const actually qualify the
function when everybody knows it doesn't.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
Am Thu, 09 Oct 2014 10:50:44 +0200
schrieb Martin Nowak c...@dawg.eu:
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.
So instead of
const int foo();
you'd should write
int foo() const;
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();`
Would this affect your code?
Do you think it makes your code better or worse?
Is this just a pointless style change?
Anything else?
https://github.com/D-Programming-Language/dmd/pull/4043
I write my function signatures like this now and I'm fine with
the change:
@safe pure nothrow @nogc [1]
final override @property ref [2] int foo() shared const [3]
{
...
}
[1] Attributes that hint the compiler by narrowing down
allowed language features.
[2] Visibility and behavioral attributes.
[3] Modifiers for implicit `this`.
--
Marco
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Fri, 10 Oct 2014 00:25:07 +0200 Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: I'm not sure whether I care to _enforce_ this style rather than strongly encourage it, as it's a breaking change. I'd rather deprecation of left-hand-side attributes, rather than illegality, if that is possible. the patch does exactly that: compiler emits deprecation warnings on prefix attributes. nobody plans to break things immediately. ;-) signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Thu, 09 Oct 2014 19:37:31 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: If we're going to break things, it needs to be for something that matters. This doesn't make the cut. ah, again... people: yes, yes, we WANT it, let's break our code and do it! Walter: ha, shut up! this doesn't matter at all, we will not break the code for this! people: rgh! (--motivation, ++frustration) i myself don't like this game enough to participate. there is no sense in both implementing something and discussing something. small fixes will be rejected due to being small, big fixes will be rejected due to being big. and medium fixes will be rejected due to being too big for small and too small for big. this game has no way to win. so at least nobody will read any more rants from me about inconsistencies in D. still a win. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
Walter Bright: If we're going to break things, it needs to be for something that matters. This doesn't make the cut. I think you are wrong. This seems a worthy little breaking change. Bye, bearophile
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote: Would this affect your code? I'll live. Do you think it makes your code better or worse? On the balance, neither. Is this just a pointless style change? Changes that mitigate patterns of human error are _never_ pointless. -Wyatt
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/9/14 10:37 PM, Walter Bright wrote: For functions, const-as-storage-class applies to the function symbol. And if it is misused, the compiler will very likely complain about a mismatched type. Can you demonstrate this? I hate to see D reject a unanimously wanted improvement on something that is likely but not defined. Breaking this adds a special case inconsistency, besides breaking existing code. Just like if(x); is rejected inconsistently. The point is, it's WORTH having the inconsistency to avoid the issues that come with it. (I understand that there's a lot of advocacy lately about break my code, but I'm the one who bears the brunt of you guys broke my code again, even though the code was correct and worked perfectly well! D sux., besides, of course, those poor souls who have to go fix their code base, and I hear again about how D is unstable, another Reddit flame-fest about D being unsuitable because the designers can't make up their mind, etc.) You need to grow a thicker skin on Reddit I think. This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) This is not a new problem, not a crazy novel syntax, and the time consumed is already taken (PR already exists). Every time I turn around, someone on D is complaining that we shouldn't spend time doing this or that. But we are all volunteers, and while it's nice to have direction, if someone wants to work on something, I don't want to say you can't do that, please work on X instead. It doesn't help, it doesn't motivate. Really, what you are saying here is, the unanimous opinion of the die-hard very dedicated D community is worthless compared to the opinion of a hypothetical Reddit user. -Steve
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Fri, 10 Oct 2014 09:42:14 -0400 Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com wrote: Really, what you are saying here is, the unanimous opinion of the die-hard very dedicated D community is worthless compared to the opinion of a hypothetical Reddit user. second-class citizens will not run away. existing D users are second-class citizens. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/14 9:53 AM, ketmar via Digitalmars-d wrote: On Fri, 10 Oct 2014 09:42:14 -0400 Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com wrote: Really, what you are saying here is, the unanimous opinion of the die-hard very dedicated D community is worthless compared to the opinion of a hypothetical Reddit user. second-class citizens will not run away. existing D users are second-class citizens. They will and have. -Steve
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via Digitalmars-d wrote: On Thu, 09 Oct 2014 19:37:31 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: If we're going to break things, it needs to be for something that matters. This doesn't make the cut. ah, again... people: yes, yes, we WANT it, let's break our code and do it! Walter: ha, shut up! this doesn't matter at all, we will not break the code for this! people: rgh! (--motivation, ++frustration) i myself don't like this game enough to participate. there is no sense in both implementing something and discussing something. small fixes will be rejected due to being small, big fixes will be rejected due to being big. and medium fixes will be rejected due to being too big for small and too small for big. this game has no way to win. so at least nobody will read any more rants from me about inconsistencies in D. still a win. yh! wait why are you still posting? gtfo
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote: On 10/9/2014 1:50 AM, 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. This has come up before, and has been debated at length. const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v In particular, const T *v; does not mean: const(T)* v; For functions, const-as-storage-class applies to the function symbol. And if it is misused, the compiler will very likely complain about a mismatched type. Breaking this adds a special case inconsistency, besides breaking existing code. (I understand that there's a lot of advocacy lately about break my code, but I'm the one who bears the brunt of you guys broke my code again, even though the code was correct and worked perfectly well! D sux., besides, of course, those poor souls who have to go fix their code base, and I hear again about how D is unstable, another Reddit flame-fest about D being unsuitable because the designers can't make up their mind, etc.) None of those professional complainers matter though. They'll always find *something* to complain about. This is an excellent example of a breaking change that pays for itself within weeks. A large codebase can be converted over very quickly, without any thought required. It has the *immediate* benefit that the coding style improves. It has the longer term benefit of removing a lot of confusion. This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) If we're going to break things, it needs to be for something that matters. This doesn't make the cut. No. It's a removal of one of those little friction points, that hurts everyone very slightly, all the time. One less thing to worry about, one less thing to explain, one less thing to be confused by. If you have an organisation with 50 people, every one of them benefits slightly. In aggregate, that's a big deal.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 04:37 AM, Walter Bright wrote: On 10/9/2014 1:50 AM, 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. This has come up before, and has been debated at length. const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v That on it's own is fairly difficult to explain. For functions, const-as-storage-class applies to the function symbol. What's the difference between a const symbol and a normal symbol? This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) Sure, programmers are obsessed with syntax discussion. Think of all the future time that is wasted discussing whether const on a function should be left or right. If we're going to break things, it needs to be for something that matters. This doesn't make the cut. There are 3591 open issues in bugzilla and hundreds of ideas floating around. So there will always be a lot of unplanned things happening in parallel. I do agree that we should handle such proposals early on through DIPs rather than stopping finished work in a pull request. We don't want to break code, but discourage the usage of LHS function qualifiers because they are confusing. As this is more about stating a clear preference than deprecating the old syntax let me propose a compromise. - adding RHS rule to D's style guide http://dlang.org/dstyle.html with an explanation what the storage class function thing does - change any dmd formatting code to RHS and change our documentation - leave the rest to linting tools like https://github.com/Hackerpilot/Dscanner
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 15:10:06 UTC, market wrote: On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via Digitalmars-d wrote: On Thu, 09 Oct 2014 19:37:31 -0700 wait why are you still posting? gtfo That kind of attitude does not help much.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 15:13:16 UTC, Don wrote: On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote: On 10/9/2014 1:50 AM, Martin Nowak wrote: No. It's a removal of one of those little friction points, that hurts everyone very slightly, all the time. As, IIRC, Teoh put it once: everywhere you turn, you see unfinished things.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 15:15:13 UTC, Martin Nowak wrote: On 10/10/2014 04:37 AM, Walter Bright wrote: On 10/9/2014 1:50 AM, Martin Nowak wrote: - leave the rest to linting tools like https://github.com/Hackerpilot/Dscanner I don't like it. If it is not in the language, then why bother with Dscanner? C++ has a lot of lint tools. How many of them the average Joe use? Either is in the language, either you can never give a * about it. Why to default to a lint tool just as a lame excuse for not getting the language right in the first place? PS I know it's not because of you.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote: const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v In particular, const T *v; does not mean: const(T)* v; Once again, I am thoroughly confused as to why the space is put before the * in a language where the * is associated with the type, and not the identifier. If it had been written like const T* v; Then it would be obvious that it means const(T*) v; At which point I ask, why word it such that 'const' affects the symbol v, and not the type T*? And why does the former syntax even exist if it is more proper to use the latter?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 8:15 AM, Martin Nowak wrote: const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v That on it's own is fairly difficult to explain. I can blame C++ for that, because in C++ the difference between const as storage class and as type constructor is much more subtle than in D, but it has critical affects. This problem is why we chose the const(T) syntax for type construction. As for what is a storage class is there any confusion about: static T v; ? I don't think so. For functions, const-as-storage-class applies to the function symbol. What's the difference between a const symbol and a normal symbol? A const field member, for example, didn't contribute to the size of the struct. We don't want to break code, but discourage the usage of LHS function qualifiers because they are confusing. As this is more about stating a clear preference than deprecating the old syntax let me propose a compromise. - adding RHS rule to D's style guide http://dlang.org/dstyle.html with an explanation what the storage class function thing does - change any dmd formatting code to RHS and change our documentation - leave the rest to linting tools like https://github.com/Hackerpilot/Dscanner That's a good idea. I have no objections.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Fri, 10 Oct 2014 15:10:05 + market via Digitalmars-d digitalmars-d@puremagic.com wrote: wait why are you still posting? can't see any technical discussion here. and can't see me ranting about inconsistencies in D. and can't see where i wrote that i will not rant about attitude. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 13:42:14 UTC, Steven Schveighoffer wrote: (I understand that there's a lot of advocacy lately about break my code, but I'm the one who bears the brunt of you guys broke my code again, even though the code was correct and worked perfectly well! D sux., besides, of course, those poor souls who have to go fix their code base, and I hear again about how D is unstable, another Reddit flame-fest about D being unsuitable because the designers can't make up their mind, etc.) You need to grow a thicker skin on Reddit I think. Or read the many Reddit comments about how C++ syntax and gotchas suck and make everyone want to avoid the language. There are only two kinds of languages: the ones people complain about and the ones nobody uses is not a joke. This is no way to design a language. And for all the supposed concern about breaking code, the most recent compiler was released with a bunch of regressions. Those are the code breakages that show up on Reddit, not minor changes that went through a proper deprecation cycle.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10 Oct 2014 17:35, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 10/10/2014 8:15 AM, Martin Nowak wrote: const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v That on it's own is fairly difficult to explain. I can blame C++ for that, because in C++ the difference between const as storage class and as type constructor is much more subtle than in D, but it has critical affects. You shouldn't be blaming C++ for mistakes that D made. This problem is why we chose the const(T) syntax for type construction. As for what is a storage class is there any confusion about: static T v; ? I don't think so. Equally, static does not have a double-meaning. Iain.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 9 Oct 2014 09:55, Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com 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. So instead of const int foo(); you'd should write int foo() const; 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();` Would this affect your code? Do you think it makes your code better or worse? Is this just a pointless style change? Anything else? https://github.com/D-Programming-Language/dmd/pull/4043 You have my full support in this. What we should first focus on it the path of least resistance to making this happen. Preferably sooner rather than later. Iain.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/14 11:15 AM, Martin Nowak wrote:
As this is more about stating a clear preference than deprecating the
old syntax let me propose a compromise.
- adding RHS rule to D's style guide http://dlang.org/dstyle.html
with an explanation what the storage class function thing does
- change any dmd formatting code to RHS and change our documentation
- leave the rest to linting tools like
https://github.com/Hackerpilot/Dscanner
This is a case of the compiler doing the *wrong* thing when requested to
do something else.
When I say:
const int
foo() { return 1;}
I mean I want foo to return a const int. The compiler does the *wrong*
thing, and instead applies const to the hidden this parameter.
In most cases, the result is a confusing error message, because most of
the time, it won't compile. But in some cases, it will compile and do
something completely incorrect.
This is not a problem of specification, this is a problem of human
semantics. The specification is sound, correct, and completely confusing
to real people.
To avoid the confusion, we put the const on the right side. While not
*completely* intuitive, it's much clearer what const applies to.
I think leaving this to a lint tool basically is as good and effective
as doing nothing. It's not a compromise at all.
-Steve
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Fri, 10 Oct 2014 13:52:30 -0400 Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com wrote: I think leaving this to a lint tool basically is as good and effective as doing nothing. this *IS* doing nothing, from any POV. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 16:44:23 UTC, ketmar via Digitalmars-d wrote: On Fri, 10 Oct 2014 15:10:05 + market via Digitalmars-d digitalmars-d@puremagic.com wrote: wait why are you still posting? can't see any technical discussion here. and can't see me ranting about inconsistencies in D. and can't see where i wrote that i will not rant about attitude. please just go. please
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 17:52:30 UTC, Steven Schveighoffer wrote: I think leaving this to a lint tool basically is as good and effective as doing nothing. It's not a compromise at all. I agree. The only people who run lint tools are established users (because they are the only ones who even know they exist). Established users are already well aware of how to use function attributes correctly (and for the most part did left-hand attributes in old code written before the informal convention came about). left-hand const is primarily a problem for new users of the language (particularly the large amount coming from C++). These users aren't running linters, they are still just trying to get basic projects off the ground. This issue is one of the top things I see new users have problems with in the D IRC channel. You can find new users having problems with it on Stack Overflow too.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, October 10, 2014 15:13:15 Don via Digitalmars-d wrote: On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote: (I understand that there's a lot of advocacy lately about break my code, but I'm the one who bears the brunt of you guys broke my code again, even though the code was correct and worked perfectly well! D sux., besides, of course, those poor souls who have to go fix their code base, and I hear again about how D is unstable, another Reddit flame-fest about D being unsuitable because the designers can't make up their mind, etc.) None of those professional complainers matter though. They'll always find *something* to complain about. This is an excellent example of a breaking change that pays for itself within weeks. A large codebase can be converted over very quickly, without any thought required. It has the *immediate* benefit that the coding style improves. It has the longer term benefit of removing a lot of confusion. Exactly! This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) If we're going to break things, it needs to be for something that matters. This doesn't make the cut. No. It's a removal of one of those little friction points, that hurts everyone very slightly, all the time. One less thing to worry about, one less thing to explain, one less thing to be confused by. If you have an organisation with 50 people, every one of them benefits slightly. In aggregate, that's a big deal. +1 - Jonathan M Davis
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
Martin Nowak wrote in message news:m15i9c$51b$1...@digitalmars.com... const int foo(); The existing behavior would be great to have if we were deliberately trying to trip up all programmers coming from C++. Kill it with fire.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, October 10, 2014 13:52:30 Steven Schveighoffer via Digitalmars-d
wrote:
On 10/10/14 11:15 AM, Martin Nowak wrote:
As this is more about stating a clear preference than deprecating the
old syntax let me propose a compromise.
- adding RHS rule to D's style guide http://dlang.org/dstyle.html
with an explanation what the storage class function thing does
- change any dmd formatting code to RHS and change our documentation
- leave the rest to linting tools like
https://github.com/Hackerpilot/Dscanner
This is a case of the compiler doing the *wrong* thing when requested to
do something else.
When I say:
const int
foo() { return 1;}
I mean I want foo to return a const int. The compiler does the *wrong*
thing, and instead applies const to the hidden this parameter.
In most cases, the result is a confusing error message, because most of
the time, it won't compile. But in some cases, it will compile and do
something completely incorrect.
This is not a problem of specification, this is a problem of human
semantics. The specification is sound, correct, and completely confusing
to real people.
To avoid the confusion, we put the const on the right side. While not
*completely* intuitive, it's much clearer what const applies to.
I think leaving this to a lint tool basically is as good and effective
as doing nothing. It's not a compromise at all.
Agreed.
Leaving this as-is in the language has almost no benefit. The only benefit is
to avoid having to make minor changes to any code which puts the const on the
left. But there's a definite cost in confusion and developer time. We've
already been telling people for ages to put const on the right whenever it
comes up, because putting it on the left is too confusing, and questions about
it keep popping up. There is a long term cost to allowing const on the left
and only a small, short term cost to deprecating it. This is one of those
cases where focusing on not breaking code definitely costs us more than making
the change, especially when we're going to be doing via the proper deprecation
mechanism and not by just changing it and breaking existing code.
- Jonathan M Davis
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Fri, 10 Oct 2014 18:14:28 + market via Digitalmars-d digitalmars-d@puremagic.com wrote: please just go. please (smiles) you are funny. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 05:19:05 +1100 Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: The existing behavior would be great to have if we were deliberately trying to trip up all programmers coming from C++. suddenly, i starting to believe that we should not deprecate prefix attributes... signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 07:52 PM, Steven Schveighoffer wrote: I think leaving this to a lint tool basically is as good and effective as doing nothing. It's not a compromise at all. So the goal is more to help D beginners who would add a const to the return type const int foo(); thinking it will work like const int x; rather than to improve readability. It still makes a lot sense to update all our documentation and the style guide. Any volunteer for the latter? Let's talk to Brian whether dfix would be able to do the rewrite automatically. https://github.com/Hackerpilot/dfix/issues/1
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via Digitalmars-d wrote: On Fri, 10 Oct 2014 18:14:28 + market via Digitalmars-d digitalmars-d@puremagic.com wrote: please just go. please (smiles) you are funny. you are not. gtfo ketmar
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 1:05 PM, market via Digitalmars-d wrote: On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via Digitalmars-d wrote: On Fri, 10 Oct 2014 18:14:28 + market via Digitalmars-d digitalmars-d@puremagic.com wrote: please just go. please (smiles) you are funny. you are not. gtfo ketmar Market, I can't tell if you're joking or not. Either way, time for it to stop.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 9:28 AM, Yota wrote: Once again, I am thoroughly confused as to why the space is put before the * in a language where the * is associated with the type, and not the identifier. In C, you can declare multiple variables like this: T *p, *q; both are pointer to T. This is why conventionally the * gets put next to the symbol name. Such split up declarations aren't allowed in D, so conventionally the * gets put next to the type, as in: T* p, q; At which point I ask, why word it such that 'const' affects the symbol v, and not the type T*? And why does the former syntax even exist if it is more proper to use the latter? const as storage class is useful for doing things like putting data into a read only segment. The const(T) type constructor syntax is to emphasize that const in D is transitive, i.e. it affects everything inside the ( ). This is not true of const in C++, which when used as a type constructor is left-associative, unless it is on the left when it becomes right-associative, which I find terribly confusing.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 20:26:23 UTC, Brad Roberts via Digitalmars-d wrote: On 10/10/2014 1:05 PM, market via Digitalmars-d wrote: On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via Digitalmars-d wrote: On Fri, 10 Oct 2014 18:14:28 + market via Digitalmars-d digitalmars-d@puremagic.com wrote: please just go. please (smiles) you are funny. you are not. gtfo ketmar Market, I can't tell if you're joking or not. Either way, time for it to stop. I am not joking! ketmar is becoming the D resident troll. And does nothing for D aside spewing shit. ketmar must gtfo.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/14 4:25 PM, Brad Roberts via Digitalmars-d wrote: On 10/10/2014 1:05 PM, market via Digitalmars-d wrote: On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via Digitalmars-d wrote: On Fri, 10 Oct 2014 18:14:28 + market via Digitalmars-d digitalmars-d@puremagic.com wrote: please just go. please (smiles) you are funny. you are not. gtfo ketmar Market, I can't tell if you're joking or not. Either way, time for it to stop. Don't feed the troll, let market go away on his own. -Steve
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote: You shouldn't be blaming C++ for mistakes that D made. I meant when perceptions about what something means are carried over from one language to another. Equally, static does not have a double-meaning. static famously in C++ has multiple meanings :-) and does so in D as well. Overloading keywords with more than one meaning is common practice and isn't necessarily bad in a programming language. In D, we overload 'this' with at least 3 distinct meanings.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 2014-10-10 19:31, Iain Buclaw via Digitalmars-d wrote: Equally, static does not have a double-meaning. static is the most overloaded keyword there is ;) -- /Jacob Carlborg
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Fri, 10 Oct 2014 13:51:54 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: Overloading keywords with more than one meaning is common practice and isn't necessarily bad in a programming language. In D, we overload 'this' with at least 3 distinct meanings. and 'enum' too. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 20:51:53 UTC, Walter Bright wrote: On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote: You shouldn't be blaming C++ for mistakes that D made. I meant when perceptions about what something means are carried over from one language to another. Yeah, but you asked for it by deliberately making D C-like. Being alike, but different is more confusing than just being different, e.g.: qualifier symbol : type; would probably have been more intuitive.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 11:11 AM, Brad Anderson wrote: left-hand const is primarily a problem for new users of the language (particularly the large amount coming from C++). These users aren't running linters, they are still just trying to get basic projects off the ground. This issue is one of the top things I see new users have problems with in the D IRC channel. You can find new users having problems with it on Stack Overflow too. Const works differently in D than in C++, and this doesn't change that. First off, const int foo(); returning const(int) is pointless. More likely, someone coming from C++ might write: const T *foo(); // in C++ returns pointer to const T expecting it to be: const(T)* foo(); // D way to return pointer to const T and: const T *p; // C++: pointer to const char // D: const pointer to const char which means different things in C++ and D. Fortunately, nearly all these issues quickly run afoul of the compiler's type checker, and can be as quickly corrected. C++ doesn't have a notion of transitive const, so the C++ syntax cannot be generally applied and have it mean the same thing. At some point, the new D user needs to spend a bit of time learning the const system and unlearning the C++ one.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10 October 2014 21:51, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote:
You shouldn't be blaming C++ for mistakes that D made.
I meant when perceptions about what something means are carried over from
one language to another.
Equally, static does not have a double-meaning.
static famously in C++ has multiple meanings :-) and does so in D as well.
I meant in the sense that it has a consistent meaning on its own,
there is no difference between the following declarations.
static int foo;
static int foo() { };
struct S { static int foo; }
struct S { static int foo() { } }
And it does not take much to explain the difference between static
alone versus static when paired with a second keyword.
static this() { }
static ~this() { }
static assert() { }
static if() { }
static import foo;
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/14 09:45, ketmar via Digitalmars-d wrote: the patch does exactly that: compiler emits deprecation warnings on prefix attributes. nobody plans to break things immediately. ;-) It's not the immediately I'm worried about, it's the eventually.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 00:49:14 +0200 Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: On 10/10/14 09:45, ketmar via Digitalmars-d wrote: the patch does exactly that: compiler emits deprecation warnings on prefix attributes. nobody plans to break things immediately. ;-) It's not the immediately I'm worried about, it's the eventually. i can't see why we should keep the syntax that nobody likes. this will just confuse newcomers. that was the argument against adding @ to nothrow and pure (and keeping the old syntax simultaneously). if it works there, it should work here too. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Friday, 10 October 2014 at 21:10:14 UTC, Walter Bright wrote: Const works differently in D than in C++, and this doesn't change that. First off, 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. 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.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 11/10/14 00:58, ketmar via Digitalmars-d wrote: i can't see why we should keep the syntax that nobody likes. this will just confuse newcomers. that was the argument against adding @ to nothrow and pure (and keeping the old syntax simultaneously). if it works there, it should work here too. I don't mind deprecating the syntax that nobody likes. I mind the idea of removing it, because has the potential to break old code for no particularly good reason. BTW I repeat, as far as I can tell, Ddoc will always place the attributes on the left of the function. That needs to be fixed if the proposed patch is to go through.
