October 10, 2014
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
October 10, 2014
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.
October 10, 2014
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.


October 10, 2014
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.
October 10, 2014
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;
October 10, 2014
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".

October 10, 2014
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.


October 10, 2014
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.
October 10, 2014
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.
October 10, 2014
On 10/10/14 04:37, Walter Bright via Digitalmars-d wrote:
> 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.