March 06, 2008
On 06/03/2008, Koroskin Denis <2korden+dmd@gmail.com> wrote:
> This syntax looks less confusing to me. Why keep both?

The syntax /is/ confusing. This is one of those "remaining const niggles" that is going to keep resurfacing until we come up with something acceptable to all.

For now, I can tell you that const-at-the-end is allowed (a) for the benefit of those used to C++ syntax, and (b) for the benefit of those who just don't like const-at-the-start. Const-at-the-start is allowed so that you can write stuff like:

    class A
    {
        const
        {
            A opAdd(A a) {...}
            A opSub(A a) {...}
            A opMul(A a) {...}
            A opDiv(A a) {...}
        }
    }

etc. Basically, it saves a lot of typing.

I know I'm repeating myself here, but I still think my previous suggestion of replacing "const" with "const(this)" and allowing it only at the front is still a good one. After all, how much extra typing, proportionately, is

    class A
    {
        const(this)
        {
            A opAdd(A a) {...}
            A opSub(A a) {...}
            A opMul(A a) {...}
            A opDiv(A a) {...}
        }
    }

? And for single functions

    const(this) T f()

is a lot less confusing than

    const T f()

as the former tells me explicitly that "this" is the thing that is const, wheras the latter makes it look like "T" is const (which it isn't).

If this is not changed, then years, even decades from now, people will still be complaining that it's confusing, and while it is true that you can get used to it, I still think it's better not to confuse in the first place.
March 06, 2008
On Thu, 06 Mar 2008 11:29:33 +0100, Koroskin Denis <2korden+dmd@gmail.com> wrote:

> On Thu, 06 Mar 2008 03:04:39 +0300, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>
>> Denton Cockburn wrote:
>>> Yep, that did the trick.
>>>
>>> IIRC, the const in front means const(this)
>>>
>>
>> and apparently const at the end means that too, now.
>>
>>         Foo opMul(const Foo [b]) const  { // also ok
>>                ...
>>          }
>>
>>
>> --bb
>
>
> This syntax looks less confusing to me. Why keep both?


I agree. With const foo x; meaning x is const, const foo y(){} meaning y is const... wait, this actually does seem to make sense when you look at it like that.

Better way to think of it: const foo x; is the same as const(foo) x;. Thus, const foo y(){}; should also mean const(foo) y(){};.

Going with how D const should apply to whatever is directly after it, foo const y(){}; appears to me the most logical way of writing it. Trailing const is also acceptable to me, seeing as there's nothing else that const could refer to.

-- Simen
March 06, 2008
On 06/03/2008, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:
>  const foo x; is the same as const(foo) x;.
>  Thus, const foo y(){}; should also mean const(foo) y(){};.

And of course, it doesn't. (Obviously, you knew that).

But that's the problem, I agree.
March 08, 2008
"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.113.1204800234.2351.digitalmars-d@puremagic.com...
> On 06/03/2008, Koroskin Denis <2korden+dmd@gmail.com> wrote:
>> This syntax looks less confusing to me. Why keep both?
>
>    class A
>    {
>        const(this)
>        {
>            A opAdd(A a) {...}
>            A opSub(A a) {...}
>            A opMul(A a) {...}
>            A opDiv(A a) {...}
>        }
>    }
>
> ? And for single functions
>
>    const(this) T f()
>
> is a lot less confusing than
>
>    const T f()
>
> as the former tells me explicitly that "this" is the thing that is
> const, wheras the latter makes it look like "T" is const (which it
> isn't).

Offhand, that sounds like a great solution to me...

Janice, why has it been "shot down" in the past?

Thanks,

- Dave

March 08, 2008
On 08/03/2008, Dave <Dave_member@pathlink.com> wrote:
>  Janice, why has it been "shot down" in the past?
>
>  Thanks,

Simple answer: Walter either doesn't like it or has more important things to work on.

In fairness, this isn't the /only/ idea which has been suggested, and I think some people did complain about the extra typing it would need. Another suggestion was

    T const f()

(the idea being that const applies to whatever is immediately to its right). I do kinda like that one too, but Walter shot that one down, primarily I think because it means you can't group multiple functions together under a single "const" attribute. The "const(this)" idea doesn't suffer from that disadvantage, but it does mean more typing, and I think that so long as "the ranks are split", so to speak, then there's no compelling reason for Walter to move to any particular choice of solution.

...indeed, I don't think he even acknowledges that there's a problem. I recall Walter saying that people will just get used to it (that's from memory, not an exact quote - I apologise if I got that wrong), in much the same way that we've got used to C++'s const syntax being inconsistent.

Personally, I like "const(this)", despite the extra typing, because it
opens the door for future expansion (e.g "const(outer)" meaning "this
function will not modify outer").

Dunno if that answers the question or not. Probably not, but I tried.
March 08, 2008
As an aside, Walter has now given us the syntax

    this(this) { ... }

for post-processing of structs after a bitwise copy. That's completely unrelated, of course, but it struck me as interesting that there is now a precedent for "this in brackets", even though in a different context.
March 08, 2008
On Sat, 08 Mar 2008 20:00:37 +0100, Janice Caron <caron800@googlemail.com> wrote:

> On 08/03/2008, Dave <Dave_member@pathlink.com> wrote:
>>  Janice, why has it been "shot down" in the past?
>>
>>  Thanks,
>
> Simple answer: Walter either doesn't like it or has more important
> things to work on.
>
> In fairness, this isn't the /only/ idea which has been suggested, and
> I think some people did complain about the extra typing it would need.
> Another suggestion was
>
>     T const f()
>
> (the idea being that const applies to whatever is immediately to its
> right). I do kinda like that one too, but Walter shot that one down,
> primarily I think because it means you can't group multiple functions
> together under a single "const" attribute. The "const(this)" idea
> doesn't suffer from that disadvantage, but it does mean more typing,
> and I think that so long as "the ranks are split", so to speak, then
> there's no compelling reason for Walter to move to any particular
> choice of solution.
>
> ...indeed, I don't think he even acknowledges that there's a problem.
> I recall Walter saying that people will just get used to it (that's
> from memory, not an exact quote - I apologise if I got that wrong), in
> much the same way that we've got used to C++'s const syntax being
> inconsistent.
>
> Personally, I like "const(this)", despite the extra typing, because it
> opens the door for future expansion (e.g "const(outer)" meaning "this
> function will not modify outer").
>
> Dunno if that answers the question or not. Probably not, but I tried.


With trailing const being allowed, I see no problem with T const f(),
and I think it is the most obvious way to write it. For preceding
'const', one logical step would be to allow only const: and const(X):
to be placed in front of functions, and disallow const T f().

-- Simen
March 08, 2008
"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.134.1205002850.2351.digitalmars-d@puremagic.com...
> On 08/03/2008, Dave <Dave_member@pathlink.com> wrote:
>>  Janice, why has it been "shot down" in the past?
>>
>>  Thanks,
>
> Simple answer: Walter either doesn't like it or has more important
> things to work on.
>
> In fairness, this isn't the /only/ idea which has been suggested, and
> I think some people did complain about the extra typing it would need.
> Another suggestion was
>
>    T const f()
>

I like that one also.

> (the idea being that const applies to whatever is immediately to its
> right). I do kinda like that one too, but Walter shot that one down,
> primarily I think because it means you can't group multiple functions
> together under a single "const" attribute. The "const(this)" idea
> doesn't suffer from that disadvantage, but it does mean more typing,
> and I think that so long as "the ranks are split", so to speak, then
> there's no compelling reason for Walter to move to any particular
> choice of solution.
>
> ...indeed, I don't think he even acknowledges that there's a problem.
> I recall Walter saying that people will just get used to it (that's
> from memory, not an exact quote - I apologise if I got that wrong), in
> much the same way that we've got used to C++'s const syntax being
> inconsistent.
>
> Personally, I like "const(this)", despite the extra typing, because it
> opens the door for future expansion (e.g "const(outer)" meaning "this
> function will not modify outer").
>
> Dunno if that answers the question or not. Probably not, but I tried.

Yes, that answers it - thanks.

I think either const(this) or T const f() are prefereable to trailing const.

March 09, 2008
"Simen Kjaeraas" <simen.kjaras@gmail.com> wrote in message news:op.t7pz1mgy1hx7vj@spill04.lan...
> On Sat, 08 Mar 2008 20:00:37 +0100, Janice Caron <caron800@googlemail.com> wrote:
>
>> On 08/03/2008, Dave <Dave_member@pathlink.com> wrote:
>>>  Janice, why has it been "shot down" in the past?
>>>
>>>  Thanks,
>>
>> Simple answer: Walter either doesn't like it or has more important
>> things to work on.
>>
>> In fairness, this isn't the /only/ idea which has been suggested, and
>> I think some people did complain about the extra typing it would need.
>> Another suggestion was
>>
>>     T const f()
>>
>> (the idea being that const applies to whatever is immediately to its
>> right). I do kinda like that one too, but Walter shot that one down,
>> primarily I think because it means you can't group multiple functions
>> together under a single "const" attribute. The "const(this)" idea
>> doesn't suffer from that disadvantage, but it does mean more typing,
>> and I think that so long as "the ranks are split", so to speak, then
>> there's no compelling reason for Walter to move to any particular
>> choice of solution.
>>
>> ...indeed, I don't think he even acknowledges that there's a problem.
>> I recall Walter saying that people will just get used to it (that's
>> from memory, not an exact quote - I apologise if I got that wrong), in
>> much the same way that we've got used to C++'s const syntax being
>> inconsistent.
>>
>> Personally, I like "const(this)", despite the extra typing, because it
>> opens the door for future expansion (e.g "const(outer)" meaning "this
>> function will not modify outer").
>>
>> Dunno if that answers the question or not. Probably not, but I tried.
>
>
> With trailing const being allowed, I see no problem with T const f(),
> and I think it is the most obvious way to write it. For preceding
> 'const', one logical step would be to allow only const: and const(X):
> to be placed in front of functions, and disallow const T f().
>
> -- Simen

Actually, now that I see that:

const T function_without_this(){}

is not allowed, I think the current idiom is acceptable because it's consistent.

March 09, 2008
"Dave" <Dave_member@pathlink.com> wrote in message news:fqv8qj$1ol3$1@digitalmars.com...
>
> I think either const(this) or T const f() are prefereable to trailing const.
>

OTOH, "T f() const" is not only familiar to C++ programmers but it is now consistent with another function modifier, 'nothrow'. And since it would then allow for:

const T function_without_this(){}

it would be yet more consistent with how const is used elsewhere with types.

Walter, is this why you added trailing const?

- Dave

1 2 3
Next ›   Last »