View mode: basic / threaded / horizontal-split · Log in · Help
March 06, 2008
Re: opMul
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
Re: opMul
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
Re: opMul
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
Re: opMul
"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
Re: opMul
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
Re: opMul
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
Re: opMul
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
Re: opMul
"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
Re: opMul
"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
Re: opMul
"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
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home