[Issue 12931] Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function

2020-02-16 Thread d-bugmail--- via Digitalmars-d-bugs
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

2020-02-03 Thread d-bugmail--- via Digitalmars-d-bugs
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

2020-02-03 Thread d-bugmail--- via Digitalmars-d-bugs
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

2020-02-03 Thread d-bugmail--- via Digitalmars-d-bugs
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

2019-08-11 Thread d-bugmail--- via Digitalmars-d-bugs
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

2014-10-20 Thread Regan Heath via Digitalmars-d

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

2014-10-19 Thread eles via Digitalmars-d

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

2014-10-19 Thread via Digitalmars-d-bugs
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

2014-10-18 Thread HaraldZealot via Digitalmars-d

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

2014-10-15 Thread Regan Heath via Digitalmars-d
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

2014-10-15 Thread Regan Heath via Digitalmars-d

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

2014-10-14 Thread Daniel Murphy via Digitalmars-d
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

2014-10-14 Thread Daniel Murphy via Digitalmars-d

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

2014-10-14 Thread John Colvin via Digitalmars-d

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

2014-10-13 Thread Lionello Lunesu via Digitalmars-d

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

2014-10-13 Thread Joseph Rushton Wakeling via Digitalmars-d

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

2014-10-13 Thread eles via Digitalmars-d
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

2014-10-13 Thread John Colvin via Digitalmars-d
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

2014-10-13 Thread deadalnix via Digitalmars-d

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

2014-10-13 Thread deadalnix via Digitalmars-d

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

2014-10-13 Thread Dicebot via Digitalmars-d
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

2014-10-13 Thread deadalnix via Digitalmars-d

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

2014-10-13 Thread Jonathan M Davis via Digitalmars-d
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

2014-10-13 Thread Joseph Rushton Wakeling via Digitalmars-d

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

2014-10-12 Thread Joseph Rushton Wakeling via Digitalmars-d

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

2014-10-12 Thread Joseph Rushton Wakeling via Digitalmars-d

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

2014-10-12 Thread Joseph Rushton Wakeling via Digitalmars-d

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

2014-10-12 Thread Timon Gehr via Digitalmars-d

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

2014-10-12 Thread via Digitalmars-d
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

2014-10-12 Thread Walter Bright via Digitalmars-d

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

2014-10-12 Thread eles via Digitalmars-d

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

2014-10-12 Thread Walter Bright via Digitalmars-d

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

2014-10-12 Thread Sean Kelly via Digitalmars-d

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

2014-10-12 Thread Martin Nowak via Digitalmars-d
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

2014-10-12 Thread Jonathan M Davis via Digitalmars-d
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

2014-10-12 Thread Walter Bright via Digitalmars-d

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

2014-10-12 Thread Martin Nowak via Digitalmars-d

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

2014-10-11 Thread monarch_dodra via Digitalmars-d

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

2014-10-11 Thread Paolo Invernizzi via Digitalmars-d

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

2014-10-11 Thread Walter Bright via Digitalmars-d

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

2014-10-11 Thread bachmeier via Digitalmars-d

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

2014-10-11 Thread Dicebot via Digitalmars-d

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

2014-10-11 Thread Dicebot via Digitalmars-d

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

2014-10-11 Thread Martin Nowak via Digitalmars-d

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

2014-10-11 Thread ketmar via Digitalmars-d
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

2014-10-11 Thread Dicebot via Digitalmars-d

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

2014-10-11 Thread ketmar gtfo via Digitalmars-d

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

2014-10-11 Thread ketmar gtfo gtfo via Digitalmars-d

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

2014-10-11 Thread monarch_dodra via Digitalmars-d

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

2014-10-11 Thread Dicebot via Digitalmars-d

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

2014-10-11 Thread Jonathan M Davis via Digitalmars-d
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

2014-10-11 Thread bearophile via Digitalmars-d

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

2014-10-11 Thread ketmar via Digitalmars-d
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

2014-10-11 Thread Brad Roberts via Digitalmars-d

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

2014-10-10 Thread deadalnix via Digitalmars-d

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

2014-10-10 Thread Marco Leise via Digitalmars-d
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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread bearophile via Digitalmars-d

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

2014-10-10 Thread Wyatt via Digitalmars-d

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

2014-10-10 Thread Steven Schveighoffer via Digitalmars-d

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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread Steven Schveighoffer via Digitalmars-d

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

2014-10-10 Thread market via Digitalmars-d

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

2014-10-10 Thread Don via Digitalmars-d

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

2014-10-10 Thread Martin Nowak via Digitalmars-d

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

2014-10-10 Thread eles via Digitalmars-d

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

2014-10-10 Thread eles via Digitalmars-d

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

2014-10-10 Thread eles via Digitalmars-d

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

2014-10-10 Thread Yota via Digitalmars-d

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

2014-10-10 Thread Walter Bright via Digitalmars-d

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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread bachmeier via Digitalmars-d
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

2014-10-10 Thread Iain Buclaw via Digitalmars-d
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

2014-10-10 Thread Iain Buclaw via Digitalmars-d
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

2014-10-10 Thread Steven Schveighoffer via Digitalmars-d

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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread market via Digitalmars-d

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

2014-10-10 Thread Brad Anderson via Digitalmars-d
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

2014-10-10 Thread Jonathan M Davis via Digitalmars-d
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

2014-10-10 Thread Daniel Murphy via Digitalmars-d

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

2014-10-10 Thread Jonathan M Davis via Digitalmars-d
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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread Martin Nowak via Digitalmars-d

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

2014-10-10 Thread market via Digitalmars-d

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

2014-10-10 Thread Brad Roberts via Digitalmars-d

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

2014-10-10 Thread Walter Bright via Digitalmars-d

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

2014-10-10 Thread market via Digitalmars-d

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

2014-10-10 Thread Steven Schveighoffer via Digitalmars-d

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

2014-10-10 Thread Walter Bright via Digitalmars-d

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

2014-10-10 Thread Jacob Carlborg via Digitalmars-d

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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread Ola Fosheim Grostad via Digitalmars-d

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

2014-10-10 Thread Walter Bright via Digitalmars-d

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

2014-10-10 Thread Iain Buclaw via Digitalmars-d
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

2014-10-10 Thread Joseph Rushton Wakeling via Digitalmars-d

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

2014-10-10 Thread ketmar via Digitalmars-d
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

2014-10-10 Thread Brad Anderson via Digitalmars-d

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

2014-10-10 Thread Joseph Rushton Wakeling via Digitalmars-d

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.


  1   2   >