Discussion:
Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
Martin Nowak via Digitalmars-d
2014-10-09 08:50:44 UTC
Permalink
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
ketmar via Digitalmars-d
2014-10-09 09:04:36 UTC
Permalink
On Thu, 09 Oct 2014 10:50:44 +0200
Post by Martin Nowak via Digitalmars-d
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'm all for this. prefix function attributes are *VERY* confusing. i
think this patch should be accepted as soon as possible. i'm already
enjoying it. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141009/dcf3d9ff/attachment.sig>
ketmar via Digitalmars-d
2014-10-09 09:12:35 UTC
Permalink
On Thu, 9 Oct 2014 12:04:36 +0300
ketmar via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

i mean there were occasional discussions in NG about irritating
"'const int bar();' is not 'const(int) bar();'" and i've seen nobody
defending prefix attributes. it was either "i don't care" or "it's
annoying".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141009/a322012b/attachment.sig>
Brian Schott via Digitalmars-d
2014-10-09 09:02:41 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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?
No. D-Scanner's style checker yells at you when you try to do
this, so I've fixed all my personal code already. These checks
run as part of the CI process at EMSI and the results are
uploaded to our local SonarQube server. We shouldn't have any
uses of the to-be-removed syntax hiding in our code.
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
Better. Explaining why "const int foo" is "const(int)" and "const
int foo();" is "int" is not something I enjoy doing.
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
No.
Post by Martin Nowak via Digitalmars-d
Anything else?
This will be moderately difficult to imlement in dfix.
francesco cattoglio via Digitalmars-d
2014-10-09 09:32:59 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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
Post by Martin Nowak via Digitalmars-d
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.
deadalnix via Digitalmars-d
2014-10-09 09:36:54 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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
Yes, yes, yes YES ! YYYEEEEEESSSSSS !
Paolo Invernizzi via Digitalmars-d
2014-10-09 09:58:31 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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'm for going ahead with that.
---
/Paolo
bearophile via Digitalmars-d
2014-10-09 10:18:58 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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;
+1 from me.
Post by Martin Nowak via Digitalmars-d
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();`
In this case I think it's better to focus on the most important
thing first.

Bye,
bearophile
Johannes Pfau via Digitalmars-d
2014-10-09 10:27:11 UTC
Permalink
Am Thu, 09 Oct 2014 10:50:44 +0200
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
Most old code, yes. I used to write all attributes on the left hand
side, but switched to right hand side some time ago.
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
Probably better, although I tried to be careful with the left hand side
attributes so it shouldn't change to much.
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
Anything else?
Code will probably look nicer, but I'm not sure if it's consistent.
with const(int) it's obvious that the return value is const. With
const int abcd() @safe
this might be less obvious.

Also fixing old code manually would be very tedious.
Johannes Pfau via Digitalmars-d
2014-10-09 10:29:45 UTC
Permalink
Am Thu, 9 Oct 2014 12:27:11 +0200
Post by Johannes Pfau via Digitalmars-d
Am Thu, 09 Oct 2014 10:50:44 +0200
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
Most old code, yes. I used to write all attributes on the left hand
side, but switched to right hand side some time ago.
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
Probably better, although I tried to be careful with the left hand
side attributes so it shouldn't change to much.
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
Anything else?
Code will probably look nicer, but I'm not sure if it's consistent.
with const(int) it's obvious that the return value is const. With
this might be less obvious.
Also fixing old code manually would be very tedious.
Forgot to some overall I'm for this change. I'd just like some
automated way to fix old code ;-)
Brian Schott via Digitalmars-d
2014-10-09 11:10:46 UTC
Permalink
Post by Johannes Pfau via Digitalmars-d
Forgot to some overall I'm for this change. I'd just like some
automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to
start getting rid of old syntax. Not long after that Walter made
this https://github.com/D-Programming-Language/dmd/pull/4021

dfix is under development. You can find it here:
https://github.com/Hackerpilot/dfix
Martin Nowak via Digitalmars-d
2014-10-09 11:30:53 UTC
Permalink
Post by Brian Schott via Digitalmars-d
https://github.com/Hackerpilot/dfix
That would make such decisions much easier :).
It doesn't appear to rewrite AST but only tokens at the moment.
How reliable is it?
Brian Schott via Digitalmars-d
2014-10-09 18:15:38 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
It doesn't appear to rewrite AST but only tokens at the moment.
The features that are implemented so far don't need the AST.
Others such as the function attributes and C-style arrays will
need help from the parser.
Post by Martin Nowak via Digitalmars-d
How reliable is it?
About four and a half. Maybe five.
Joakim via Digitalmars-d
2014-10-09 17:14:30 UTC
Permalink
On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau
Post by Johannes Pfau via Digitalmars-d
Forgot to some overall I'm for this change. I'd just like some
automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to
start getting rid of old syntax. Not long after that Walter
made this
https://github.com/D-Programming-Language/dmd/pull/4021
https://github.com/Hackerpilot/dfix
This is great news. Even if it's not going to be packaged with
the official compiler releases, perhaps you can start off by
making it available on dub for any breaking syntax changes in
dmd, such as ditching the old C-style array declaration syntax,
so we can point users who hit it at dfix.

As for moving function attributes from the left to the right, I'm
all for it. I was frequently confused by what applied to what
and picking through and figuring it out was unnecessary mental
overhead.
Walter Bright via Digitalmars-d
2014-10-10 03:22:30 UTC
Permalink
Post by Johannes Pfau via Digitalmars-d
Forgot to some overall I'm for this change. I'd just like some
automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to start getting rid
of old syntax. Not long after that Walter made this
https://github.com/D-Programming-Language/dmd/pull/4021
https://github.com/Hackerpilot/dfix
dfix will be a welcome addition. Glad you're working on it!
Daniel Kozak via Digitalmars-d
2014-10-09 10:51:30 UTC
Permalink
V Thu, 09 Oct 2014 10:50:44 +0200
Post by Martin Nowak via Digitalmars-d
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?
Yes (but I am ok with that)
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
Definitely better
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
No
Post by Martin Nowak via Digitalmars-d
Anything else?
Merge this ASAP, please :)
Robert burner Schadek via Digitalmars-d
2014-10-09 11:24:07 UTC
Permalink
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:>
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
no
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
no change, my code already looks like that
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
no, left hand side function qualifier is just wrong IMO.
Post by Martin Nowak via Digitalmars-d
Anything else?
Thank you guys
Sag Academy via Digitalmars-d
2014-10-09 11:30:46 UTC
Permalink
On Thursday, 9 October 2014 at 11:24:08 UTC, Robert burner
Post by Robert burner Schadek via Digitalmars-d
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak
wrote:>
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
no
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
no change, my code already looks like that
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
no, left hand side function qualifier is just wrong IMO.
Post by Martin Nowak via Digitalmars-d
Anything else?
Thank you guys
mostly welcome
monarch_dodra via Digitalmars-d
2014-10-09 11:38:35 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
I've written code before in the style:
@property pure nothrow const //<- HERE
int foo();

So anybody else using this style might be affected.

But even then, I agree. D has always been about "if it's
ambiguous, dangerous, and can be avoided, don't make it fucking
legal".
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
Is this just a pointless style change?
Anything else?
I'm not really sure about the: "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 don't think it buys us anything, except maybe silently changing
semantics of code that hibernated through the deprecation process.

I mean, sure, it might be a little surprising, but it's not the
end of the world.
Joseph Rushton Wakeling via Digitalmars-d
2014-10-09 22:29:21 UTC
Permalink
I'm not really sure about the: "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 don't think it buys us anything, except maybe silently changing semantics of
code that hibernated through the deprecation process.
Besides,

const int foo() const
{
...
}

is fairly ambiguous syntax to my eyes.

const(int) foo() const
{
...
}

is less so.
deadalnix via Digitalmars-d
2014-10-10 00:47:59 UTC
Permalink
On Thursday, 9 October 2014 at 22:29:32 UTC, Joseph Rushton
Post by Joseph Rushton Wakeling via Digitalmars-d
Post by monarch_dodra via Digitalmars-d
I'm not really sure about the: "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 don't think it buys us anything, except maybe silently
changing semantics of
code that hibernated through the deprecation process.
Besides,
const int foo() const
{
...
}
is fairly ambiguous syntax to my eyes.
const(int) foo() const
{
...
}
is less so.
Also

const int delegate() const dg;

Is dg const or the return type ?
Dominikus Dittes Scherkl via Digitalmars-d
2014-10-09 11:40:29 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
No, I always wrote it on the right.
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
Better.
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
No, removing confusing style is good.
Atila Neves via Digitalmars-d
2014-10-09 12:11:21 UTC
Permalink
This pull request is a good thing (TM). +1 all the way.

Atila
Post by Martin Nowak via Digitalmars-d
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
Martin Drašar via Digitalmars-d
2014-10-09 12:58:22 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
yes, but I understand the rationale so I don't mind
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
less ambiguous, so I would say better
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
no

--
Martin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3279 bytes
Desc: Elektronicky podpis S/MIME
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141009/9fc3a9bd/attachment.bin>
Dicebot via Digitalmars-d
2014-10-09 13:37:30 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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;
Finally.
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
Yes, eventually, but I am willing to make the change and it is
trivial compared to some other D2 migration related things :)
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
Is this just a pointless style change?
I believe it is much less error-prone, prefix notation is
currently a common cause of mis-interpretation from the reader.
Steven Schveighoffer via Digitalmars-d
2014-10-09 14:17:48 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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
First, I'm all for the change. If it affects my code, I don't care, I'll
fix it.

Just one point to make, this will still work, right?:

const {
int foo();
}

const:
int foo();

I'm not sure I agree with the future plan to allow const on the lhs to
apply to the return type, but we can decide that in the future.

-Steve
Kenji Hara via Digitalmars-d
2014-10-09 15:08:39 UTC
Permalink
2014-10-09 23:17 GMT+09:00 Steven Schveighoffer via Digitalmars-d <
Post by Steven Schveighoffer via Digitalmars-d
const {
int foo();
}
int foo();
My PR still allows those block or label style attributes.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/e3337d78/attachment.html>
Sean Kelly via Digitalmars-d
2014-10-09 16:16:34 UTC
Permalink
It's a clean break and easy to fix, and eliminated a confusing
ambiguity. I'm all for it.
Brad Anderson via Digitalmars-d
2014-10-09 16:46:48 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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.
+1.

Prefixed const is so often a mistaken attempt to return a const
that when I see someone post for help in IRC about "cannot
implicitly convert expression" I immediately look for a "this" in
the error message because that usually means they are using
prefixed const function attribute when they intended to return a
const variable.

This reminds me quite a bit about Walter's explanation on FLOSS
Weekly about why D disallows shadowing local variables. It can be
used correctly just fine but it's so often used incorrectly that
we're better off disallowing it completely.
Jonathan M Davis via Digitalmars-d
2014-10-09 18:31:04 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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
Well, since I'm the one who created the enhancement request that this is for,
I'm obviously for it. It's a change that's long past due. Allowing them on the
left only causes trouble - both in terms of bugs and confusion - and I think
that most of us would agree that it's already considered good practice to
stick them on the right rather than the left. Allowing them on the left has no
real benefit IMHO beyond avoiding code breakage, and the fix for that is
trivial.

- Jonathan M Davis
Gary Willoughby via Digitalmars-d
2014-10-09 21:28:04 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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.
Great. I support this.
Joseph Rushton Wakeling via Digitalmars-d
2014-10-09 22:25:07 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
No, but is it fixed on the ddoc side? The last ddoc I generated had function
attributes first, even though in the code they were on the right. It would be
pretty awful to have function attributes obliged to be on the right in code, but
still appearing on the left in documentation.
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
I like the style, and it certainly helps to avoid the confusion with C/C++'s
const interpretation.
Post by Martin Nowak via Digitalmars-d
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 like this idea less. const(int) is explicit in a way that const int isn't.
Post by Martin Nowak via Digitalmars-d
Anything else?
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.
ketmar via Digitalmars-d
2014-10-10 07:45:55 UTC
Permalink
On Fri, 10 Oct 2014 00:25:07 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Joseph Rushton Wakeling via Digitalmars-d
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. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/817eecfa/attachment.sig>
Joseph Rushton Wakeling via Digitalmars-d
2014-10-10 22:49:14 UTC
Permalink
Post by ketmar via Digitalmars-d
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".
ketmar via Digitalmars-d
2014-10-10 22:58:32 UTC
Permalink
On Sat, 11 Oct 2014 00:49:14 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Joseph Rushton Wakeling via Digitalmars-d
Post by ketmar via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141011/581cd16f/attachment-0001.sig>
Joseph Rushton Wakeling via Digitalmars-d
2014-10-10 23:13:51 UTC
Permalink
Post by ketmar via Digitalmars-d
i can't see why we should keep the syntax that nobody likes. this will
"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.
ketmar via Digitalmars-d
2014-10-10 23:20:06 UTC
Permalink
On Sat, 11 Oct 2014 01:13:51 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Joseph Rushton Wakeling via Digitalmars-d
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.
there is good reason: this syntax is confusing. if it will stay as
deprecated, newcomers will have just one more question: "why it's still
here?"

and about breaking old code. if this code is so old that nobody will
fix it... well, one can use old compiler to build that code. but that
code rot many years ago anyway: it's unmaintained. it *will* break
sooner or later, there is no sane reason to trying to keep zombie
alive, zombies must be destroyed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141011/a8c5f948/attachment.sig>
Walter Bright via Digitalmars-d
2014-10-10 02:37:31 UTC
Permalink
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.)

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.
deadalnix via Digitalmars-d
2014-10-10 06:34:19 UTC
Permalink
Post by Walter Bright via Digitalmars-d
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.
ketmar via Digitalmars-d
2014-10-10 07:52:54 UTC
Permalink
On Thu, 09 Oct 2014 19:37:31 -0700
Post by Walter Bright via Digitalmars-d
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: aaaargh! (--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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/c65fbb9e/attachment.sig>
bearophile via Digitalmars-d
2014-10-10 08:04:53 UTC
Permalink
Post by Walter Bright via Digitalmars-d
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
Steven Schveighoffer via Digitalmars-d
2014-10-10 13:42:14 UTC
Permalink
Post by Walter Bright via Digitalmars-d
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.
Post by Walter Bright via Digitalmars-d
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.
Post by Walter Bright via Digitalmars-d
(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.
Post by Walter Bright via Digitalmars-d
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
ketmar via Digitalmars-d
2014-10-10 13:53:17 UTC
Permalink
On Fri, 10 Oct 2014 09:42:14 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Steven Schveighoffer via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/2ea55df5/attachment.sig>
Steven Schveighoffer via Digitalmars-d
2014-10-10 15:03:46 UTC
Permalink
Post by ketmar via Digitalmars-d
On Fri, 10 Oct 2014 09:42:14 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Steven Schveighoffer via Digitalmars-d
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
bachmeier via Digitalmars-d
2014-10-10 17:15:07 UTC
Permalink
On Friday, 10 October 2014 at 13:42:14 UTC, Steven Schveighoffer
Post by Steven Schveighoffer via Digitalmars-d
Post by Walter Bright via Digitalmars-d
(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.
market via Digitalmars-d
2014-10-10 15:10:05 UTC
Permalink
On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Thu, 09 Oct 2014 19:37:31 -0700
Walter Bright via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Walter Bright via Digitalmars-d
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: aaaargh! (--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.
yoooohoooo!

wait.... why are you still posting? gtfo
eles via Digitalmars-d
2014-10-10 15:22:34 UTC
Permalink
Post by market via Digitalmars-d
On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Thu, 09 Oct 2014 19:37:31 -0700
wait.... why are you still posting? gtfo
That kind of attitude does not help much.
ketmar via Digitalmars-d
2014-10-10 16:44:12 UTC
Permalink
On Fri, 10 Oct 2014 15:10:05 +0000
Post by market via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/0c6f0961/attachment.sig>
market via Digitalmars-d
2014-10-10 18:14:28 UTC
Permalink
On Friday, 10 October 2014 at 16:44:23 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Fri, 10 Oct 2014 15:10:05 +0000
Post by market via Digitalmars-d
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
ketmar via Digitalmars-d
2014-10-10 19:14:40 UTC
Permalink
On Fri, 10 Oct 2014 18:14:28 +0000
Post by market via Digitalmars-d
please just go. please
(smiles) you are funny.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/9201b386/attachment.sig>
market via Digitalmars-d
2014-10-10 20:05:03 UTC
Permalink
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Fri, 10 Oct 2014 18:14:28 +0000
Post by market via Digitalmars-d
please just go. please
(smiles) you are funny.
you are not. gtfo ketmar
Brad Roberts via Digitalmars-d
2014-10-10 20:25:51 UTC
Permalink
Post by market via Digitalmars-d
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Fri, 10 Oct 2014 18:14:28 +0000
Post by market via Digitalmars-d
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.
market via Digitalmars-d
2014-10-10 20:41:45 UTC
Permalink
On Friday, 10 October 2014 at 20:26:23 UTC, Brad Roberts via
Post by Brad Roberts via Digitalmars-d
Post by market via Digitalmars-d
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Fri, 10 Oct 2014 18:14:28 +0000
Post by market via Digitalmars-d
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.
Steven Schveighoffer via Digitalmars-d
2014-10-10 20:48:34 UTC
Permalink
Post by Brad Roberts via Digitalmars-d
Post by market via Digitalmars-d
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Fri, 10 Oct 2014 18:14:28 +0000
Post by market via Digitalmars-d
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
Don via Digitalmars-d
2014-10-10 15:13:15 UTC
Permalink
Post by Walter Bright via Digitalmars-d
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
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;
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.
Post by Walter Bright via Digitalmars-d
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.
eles via Digitalmars-d
2014-10-10 15:27:21 UTC
Permalink
Post by Don via Digitalmars-d
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.
Jonathan M Davis via Digitalmars-d
2014-10-10 18:17:06 UTC
Permalink
Post by Don via Digitalmars-d
Post by Walter Bright via Digitalmars-d
(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!
Post by Don via Digitalmars-d
Post by Walter Bright via Digitalmars-d
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
Martin Nowak via Digitalmars-d
2014-10-10 15:15:04 UTC
Permalink
Post by Walter Bright via Digitalmars-d
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
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.
Post by Walter Bright via Digitalmars-d
For functions, const-as-storage-class applies to the function symbol.
What's the difference between a const symbol and a normal symbol?
Post by Walter Bright via Digitalmars-d
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.
Post by Walter Bright via Digitalmars-d
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
eles via Digitalmars-d
2014-10-10 15:25:48 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
- 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.
Walter Bright via Digitalmars-d
2014-10-10 16:32:56 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
Post by Walter Bright via Digitalmars-d
const is used both as a storage class and as a type constructor, and is
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.
Post by Martin Nowak via Digitalmars-d
Post by Walter Bright via Digitalmars-d
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.
Post by Martin Nowak via Digitalmars-d
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.
Iain Buclaw via Digitalmars-d
2014-10-10 17:31:46 UTC
Permalink
On 10 Oct 2014 17:35, "Walter Bright via Digitalmars-d" <
Post by Walter Bright via Digitalmars-d
Post by Martin Nowak via Digitalmars-d
Post by Walter Bright via Digitalmars-d
const is used both as a storage class and as a type constructor, and is
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.
Post by Walter Bright via Digitalmars-d
This problem is why we chose the const(T) syntax for type construction.
static T v;
? I don't think so.
Equally, static does not have a double-meaning.

Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/f9dc7655/attachment.html>
Walter Bright via Digitalmars-d
2014-10-10 20:51:54 UTC
Permalink
Post by Iain Buclaw via Digitalmars-d
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.
Post by Iain Buclaw via Digitalmars-d
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.
ketmar via Digitalmars-d
2014-10-10 21:05:40 UTC
Permalink
On Fri, 10 Oct 2014 13:51:54 -0700
Post by Walter Bright via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141011/ae2afa44/attachment.sig>
Ola Fosheim Grostad via Digitalmars-d
2014-10-10 21:05:23 UTC
Permalink
Post by Walter Bright via Digitalmars-d
Post by Iain Buclaw via Digitalmars-d
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.
Iain Buclaw via Digitalmars-d
2014-10-10 21:40:13 UTC
Permalink
On 10 October 2014 21:51, Walter Bright via Digitalmars-d
Post by Walter Bright via Digitalmars-d
Post by Iain Buclaw via Digitalmars-d
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.
Post by Iain Buclaw via Digitalmars-d
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;
Jacob Carlborg via Digitalmars-d
2014-10-10 20:56:00 UTC
Permalink
Post by Iain Buclaw via Digitalmars-d
Equally, static does not have a double-meaning.
"static" is the most overloaded keyword there is ;)
--
/Jacob Carlborg
Steven Schveighoffer via Digitalmars-d
2014-10-10 17:52:30 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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
ketmar via Digitalmars-d
2014-10-10 18:01:48 UTC
Permalink
On Fri, 10 Oct 2014 13:52:30 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Steven Schveighoffer via Digitalmars-d
I think leaving this to a lint tool basically is as good and
effective as doing nothing.
this *IS* doing nothing, from any POV.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/dcc3cb46/attachment.sig>
Brad Anderson via Digitalmars-d
2014-10-10 18:11:41 UTC
Permalink
On Friday, 10 October 2014 at 17:52:30 UTC, Steven Schveighoffer
Post by Steven Schveighoffer via Digitalmars-d
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.
Walter Bright via Digitalmars-d
2014-10-10 21:10:16 UTC
Permalink
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.
Brad Anderson via Digitalmars-d
2014-10-10 23:04:39 UTC
Permalink
Post by Walter Bright via Digitalmars-d
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.
Jonathan M Davis via Digitalmars-d
2014-10-10 18:22:08 UTC
Permalink
On Friday, October 10, 2014 13:52:30 Steven Schveighoffer via Digitalmars-d
Post by Steven Schveighoffer via Digitalmars-d
Post by Martin Nowak via Digitalmars-d
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.
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
Martin Nowak via Digitalmars-d
2014-10-10 20:00:26 UTC
Permalink
Post by Steven Schveighoffer via Digitalmars-d
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
Yota via Digitalmars-d
2014-10-10 16:28:18 UTC
Permalink
Post by Walter Bright via Digitalmars-d
const is used both as a storage class and as a type
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;
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?
Walter Bright via Digitalmars-d
2014-10-10 20:36:13 UTC
Permalink
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.
Joseph Rushton Wakeling via Digitalmars-d
2014-10-10 23:16:27 UTC
Permalink
Post by Walter Bright via Digitalmars-d
If we're going to break things, it needs to be for something that matters. This
doesn't make the cut.
I agree with that general sentiment, but doesn't this patch only deprecate
left-hand-side function attributes?

I don't particularly mind you refusing it, but deprecation (in support of good
stylistic practice) isn't breaking.
Dicebot via Digitalmars-d
2014-10-11 04:11:29 UTC
Permalink
Post by Walter Bright via Digitalmars-d
This has come up before, and has been debated at length.
const is used both as a storage class and as a type
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;
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;

???

I see no point in saying const storage class exists in D2 because
there is no way to observe it because of transitivity of const
qualifier.
Post by Walter Bright via Digitalmars-d
(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.)
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.
Post by Walter Bright via Digitalmars-d
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
monarch_dodra via Digitalmars-d
2014-10-11 07:36:20 UTC
Permalink
Post by Dicebot via Digitalmars-d
Post by Walter Bright via Digitalmars-d
This has come up before, and has been debated at length.
const is used both as a storage class and as a type
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;
const(T)* v;
const T var;
const(T) var;
No, look at the pointer symbol.
Post by Dicebot via Digitalmars-d
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
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.
Post by Walter Bright via Digitalmars-d
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.
Post by Dicebot via Digitalmars-d
#pleasebreakourcode
Lol.
Dicebot via Digitalmars-d
2014-10-11 12:45:39 UTC
Permalink
Post by monarch_dodra via Digitalmars-d
Post by Dicebot via Digitalmars-d
const T var;
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

0000000000000000 B _D4test1axPPi
0000000000000008 B _D4test1bxPPi

???

Can you give an examle of the code that actually observes the
semantical difference?
monarch_dodra via Digitalmars-d
2014-10-11 17:27:20 UTC
Permalink
On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra
Post by monarch_dodra via Digitalmars-d
Post by Dicebot via Digitalmars-d
const T var;
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
0000000000000000 B _D4test1axPPi
0000000000000008 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".
Dicebot via Digitalmars-d
2014-10-11 21:17:47 UTC
Permalink
Post by monarch_dodra via Digitalmars-d
On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra
Post by monarch_dodra via Digitalmars-d
Post by Dicebot via Digitalmars-d
const T var;
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.
Paolo Invernizzi via Digitalmars-d
2014-10-11 07:50:14 UTC
Permalink
Post by Dicebot via Digitalmars-d
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
Post by Dicebot via Digitalmars-d
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
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.
Post by Walter Bright via Digitalmars-d
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
bachmeier via Digitalmars-d
2014-10-11 10:18:28 UTC
Permalink
Post by Dicebot via Digitalmars-d
#pleasebreakourcode
No, it's #pleasedeprecateourcode

For a change like this, with proper deprecation, there will be no
broken code.
Dicebot via Digitalmars-d
2014-10-11 12:40:42 UTC
Permalink
Post by bachmeier via Digitalmars-d
Post by Dicebot via Digitalmars-d
#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
Brad Roberts via Digitalmars-d
2014-10-11 23:31:57 UTC
Permalink
Post by bachmeier via Digitalmars-d
Post by Dicebot via Digitalmars-d
#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.
Walter Bright via Digitalmars-d
2014-10-11 09:16:42 UTC
Permalink
Post by Joseph Rushton Wakeling via Digitalmars-d
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() { ... }
Post by Joseph Rushton Wakeling via Digitalmars-d
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.
Joseph Rushton Wakeling via Digitalmars-d
2014-10-12 09:28:49 UTC
Permalink
Post by Walter Bright via Digitalmars-d
Post by Joseph Rushton Wakeling via Digitalmars-d
I agree with that general sentiment, but doesn't this patch only deprecate
left-hand-side function attributes?
pure int foo() { ... }
Not good. If LHS function attributes are to be deprecated, it really ought to
be all or nothing.
Post by Walter Bright via Digitalmars-d
Post by Joseph Rushton Wakeling via Digitalmars-d
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.

Marco Leise via Digitalmars-d
2014-10-10 07:42:38 UTC
Permalink
Am Thu, 09 Oct 2014 10:50:44 +0200
Post by Martin Nowak via Digitalmars-d
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
Wyatt via Digitalmars-d
2014-10-10 13:28:33 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
Would this affect your code?
I'll live.
Post by Martin Nowak via Digitalmars-d
Do you think it makes your code better or worse?
On the balance, neither.
Post by Martin Nowak via Digitalmars-d
Is this just a pointless style change?
Changes that mitigate patterns of human error are _never_
pointless.

-Wyatt
Iain Buclaw via Digitalmars-d
2014-10-10 17:35:08 UTC
Permalink
On 9 Oct 2014 09:55, "Martin Nowak via Digitalmars-d" <
Post by Martin Nowak via Digitalmars-d
Kenji just proposed a slightly controversial pull request so I want to
reach out for more people to discuss it's tradeoffs.
Post by Martin Nowak via Digitalmars-d
It's about deprecating function qualifiers on the left hand side of a
function.
Post by Martin Nowak via Digitalmars-d
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();`
Post by Martin Nowak via Digitalmars-d
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/8363b7a7/attachment.html>
Daniel Murphy via Digitalmars-d
2014-10-10 18:19:05 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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.
ketmar via Digitalmars-d
2014-10-10 19:19:02 UTC
Permalink
On Sat, 11 Oct 2014 05:19:05 +1100
Post by Daniel Murphy via Digitalmars-d
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141010/ed7cbf48/attachment.sig>
Martin Nowak via Digitalmars-d
2014-10-11 12:47:55 UTC
Permalink
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.
ketmar via Digitalmars-d
2014-10-11 13:00:22 UTC
Permalink
On Sat, 11 Oct 2014 14:47:55 +0200
Post by Martin Nowak via Digitalmars-d
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141011/28aa6911/attachment.sig>
Dicebot via Digitalmars-d
2014-10-11 13:40:11 UTC
Permalink
Post by 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.
Sounds good but what is the benefit over just having deprecation
period 6 months longer?
ketmar gtfo via Digitalmars-d
2014-10-11 15:17:35 UTC
Permalink
On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Sat, 11 Oct 2014 14:47:55 +0200
Martin Nowak via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Martin Nowak via Digitalmars-d
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
ketmar gtfo gtfo via Digitalmars-d
2014-10-11 15:35:51 UTC
Permalink
Post by ketmar gtfo via Digitalmars-d
On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via
Post by ketmar via Digitalmars-d
On Sat, 11 Oct 2014 14:47:55 +0200
Martin Nowak via Digitalmars-d <digitalmars-d at puremagic.com>
Post by Martin Nowak via Digitalmars-d
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
Jonathan M Davis via Digitalmars-d
2014-10-11 22:33:12 UTC
Permalink
Post by Martin Nowak via Digitalmars-d
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
bearophile via Digitalmars-d
2014-10-11 22:41:50 UTC
Permalink
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
ketmar via Digitalmars-d
2014-10-11 23:09:48 UTC
Permalink
On Sat, 11 Oct 2014 22:41:50 +0000
Post by bearophile via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141012/2878d42b/attachment-0001.sig>
Loading...