• "Bill Baxter" <wbaxter gmail.com> Sep 08 2008
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Sep 08 2008
• "Stewart Gordon" <smjg_1998 yahoo.com> Sep 11 2008
• Tomas Lindquist Olsen <tomas famolsen.dk> Sep 11 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Sep 11 2008
• "Stewart Gordon" <smjg_1998 yahoo.com> Sep 11 2008
• Benji Smith <dlanguage benjismith.net> Sep 11 2008
• Sclytrack <sclytrack pi.be> Sep 12 2008
• Alix Pexton <_a_l_i_x_._p_e_x_t_o_n_ _g_m_a_i_l_._c_o_m_> Sep 12 2008
• "Stewart Gordon" <smjg_1998 yahoo.com> Sep 12 2008
• Benji Smith <dlanguage benjismith.net> Sep 12 2008
• "Bill Baxter" <wbaxter gmail.com> Sep 11 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Sep 11 2008
• "Bill Baxter" <wbaxter gmail.com> Sep 11 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Sep 12 2008

"Bill Baxter" <wbaxter gmail.com> writes:

On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. The
 hack of using __dollar is bad (although it works).


 It doesn't work for multiple dimensions. There should be an opDollar(uint
 dim) that gives the library information on which argument count it occured
 in. Consider:

 auto x = matrix[$-1, $-1];

 Here the dollar's occurrences have different meanings. A good start would be
 to expand the above into:

 auto x = matrix[matrix.opDollar(0)-1, matrix.opDollar(1)-1];


Actually __dollar can be made to work with a bit of overhead.  Make
__dollar be a particular struct type, say EndRelativeIndex, that holds
an integer offset and has overloaded opAdd and opSub, then make
overloads for Matrix opIndex that accept that struct type.  A
"sufficiently smart compiler" could probably even get rid of the
overhead.

But all that trickery would be unnecessary if opDollar existed and
behaved as you suggest.

--bb

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Bill Baxter wrote:
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. The
 hack of using __dollar is bad (although it works).


 dim) that gives the library information on which argument count it occured
 in. Consider:

 auto x = matrix[$-1, $-1];

 Here the dollar's occurrences have different meanings. A good start would be
 to expand the above into:

 auto x = matrix[matrix.opDollar(0)-1, matrix.opDollar(1)-1];


 Actually __dollar can be made to work with a bit of overhead.  Make
 __dollar be a particular struct type, say EndRelativeIndex, that holds
 an integer offset and has overloaded opAdd and opSub, then make
 overloads for Matrix opIndex that accept that struct type.  A
 "sufficiently smart compiler" could probably even get rid of the
 overhead.
 
 But all that trickery would be unnecessary if opDollar existed and
 behaved as you suggest.


That's a nice trick! But shhh, let's convince Walter do the right thing 
while he's bent on making ranges work.

Andrei

"Stewart Gordon" <smjg_1998 yahoo.com> writes:

"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. 
 The
 hack of using __dollar is bad (although it works).






Agreed.

 It doesn't work for multiple dimensions. There should be an opDollar(uint
 dim) that gives the library information on which argument count it 
 occured
 in. Consider:





opDollar is the wrong choice of name.  The op* methods are - as a rule - 
named after the semantic function of the operator, rather than what the 
operator looks like.  For example, opMul not opAsterisk, opIndex not 
opSquareBrackets.  Consequently, opStar is already inconsistently named; I 
think one such is enough.  As for what the function to overload $ should be 
called ... how about opEnd?

Where did this conversation begin?  I can't seem to find any messages up the 
thread from the one I'm replying to now.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit. 

Tomas Lindquist Olsen <tomas famolsen.dk> writes:

Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user 
 containers. The
 hack of using __dollar is bad (although it works).






 Agreed.
 
 It doesn't work for multiple dimensions. There should be an 
 opDollar(uint
 dim) that gives the library information on which argument count it 
 occured
 in. Consider:




 
 opDollar is the wrong choice of name.  The op* methods are - as a rule - 
 named after the semantic function of the operator, rather than what the 
 operator looks like.  For example, opMul not opAsterisk, opIndex not 
 opSquareBrackets.  Consequently, opStar is already inconsistently named; 
 I think one such is enough.  As for what the function to overload $ 
 should be called ... how about opEnd?
 
 Where did this conversation begin?  I can't seem to find any messages up 
 the thread from the one I'm replying to now.
 
 Stewart.
 


Since $ is used as a shortcut for for array.length, I'd say opLength is a
better choice. Maybe 
I missed some of the discussion ...

-Tomas

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Tomas Lindquist Olsen" wrote
 Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. 
 The
 hack of using __dollar is bad (although it works).






 Agreed.

 It doesn't work for multiple dimensions. There should be an 
 opDollar(uint
 dim) that gives the library information on which argument count it 
 occured
 in. Consider:





 opDollar is the wrong choice of name.  The op* methods are - as a rule - 
 named after the semantic function of the operator, rather than what the 
 operator looks like.  For example, opMul not opAsterisk, opIndex not 
 opSquareBrackets.  Consequently, opStar is already inconsistently named; 
 I think one such is enough.  As for what the function to overload $ 
 should be called ... how about opEnd?

 Where did this conversation begin?  I can't seem to find any messages up 
 the thread from the one I'm replying to now.

 Stewart.


 Since $ is used as a shortcut for for array.length, I'd say opLength is a 
 better choice. Maybe I missed some of the discussion ...


I'd agree with opEnd.  opLength is only a valid construct for arrays, where 
the slice indexes are based on how far into the container the element is.

For example, if you wanted to 'slice' an AA, you would use 2 keys for the 
slice 'indexes', what if the keys are strings?

-Steve 

"Stewart Gordon" <smjg_1998 yahoo.com> writes:

"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:gabkfm$2q5j$1 digitalmars.com...
 "Tomas Lindquist Olsen" wrote


 Since $ is used as a shortcut for for array.length, I'd say opLength is a 
 better choice. Maybe I missed some of the discussion ...


 I'd agree with opEnd.  opLength is only a valid construct for arrays, 
 where the slice indexes are based on how far into the container the 
 element is.



Moreover, 'end' and 'length' correspond only in the case of _zero-based_ 
arrays.  If you create a class that implements 10-based arrays, you'll more 
likely want this notation for the end of the array than for the element 
that's 10 away from the end.

You could even invent signed-index arrays - maybe there's a use for indexes 
ranging from -16 to 15 inclusive, IWC -$ would signify the beginning.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit. 

Benji Smith <dlanguage benjismith.net> writes:

Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:10 AM, Steven Schveighoffer
 size doesn't work for slices that don't use sequential integers as index.
 i.e. imagine a sorted map (such as tree map) slice:

 I much prefer 'end' or 'last'.  It reads natural.  From the "one" element to
 the end.


 Ok, so you want to change the meaning of $ altogether from being a
 number to something container dependent?


Also, even when $ is a number, it isn't the index of the "end" node or 
the "last" element. It's the index *after* the last element.

I think only "length" or "size" are accurate.

--benji

Sclytrack <sclytrack pi.be> writes:

 Ok, so you want to change the meaning of $ altogether from being a
 number to something container dependent?


 the "last" element. It's the index *after* the last element.
 I think only "length" or "size" are accurate.



	size is the size in bytes
	length is the number of elements
	norm is the length, darn.

Alix Pexton <_a_l_i_x_._p_e_x_t_o_n_ _g_m_a_i_l_._c_o_m_> writes:

Sclytrack wrote:
 Ok, so you want to change the meaning of $ altogether from being a
 number to something container dependent?


 the "last" element. It's the index *after* the last element.
 I think only "length" or "size" are accurate.


 
 	size is the size in bytes
 	length is the number of elements
 	norm is the length, darn.


I like the sound of opTerminus as the function behind $

^^

A...

"Stewart Gordon" <smjg_1998 yahoo.com> writes:

"Benji Smith" <dlanguage benjismith.net> wrote in message 
news:gacrn7$221v$1 digitalmars.com...
<snip>
 Also, even when $ is a number, it isn't the index of the "end" node or the 
 "last" element. It's the index *after* the last element.

 I think only "length" or "size" are accurate.


So you think that, in the case of a 3-based array type, $ should be the 
index of the antepenultimate element?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit. 

Benji Smith <dlanguage benjismith.net> writes:

Stewart Gordon wrote:
 "Benji Smith" <dlanguage benjismith.net> wrote in message 
 news:gacrn7$221v$1 digitalmars.com...
 <snip>
 Also, even when $ is a number, it isn't the index of the "end" node or 
 the "last" element. It's the index *after* the last element.

 I think only "length" or "size" are accurate.


 So you think that, in the case of a 3-based array type, $ should be the 
 index of the antepenultimate element?
 
 Stewart.


I didn't say anything about what it *should* mean. I was just saying 
that it certainly doesn't refer to the last element.

I have mixed feelings about what $ should mean. In an array slice, it 
makes sense for $ to be the length, because slicing uses an open range 
on the right-hand side

    array[0..5] // selects elements 0 - 4
    array[5..$] // selects everything from 5 to the end

But I also think the $, when used alone in an array index, ought to 
refer to the last element:

    array[$] // ideally: selects the last element.

Of course, the way it really works right now is like this:

    array[$ - 1] // awkward: selects last element
    array[$] // out of bounds. access violation.

So, I'm not really sure what I want. Above all, I think $ should have a 
consistent meaning.

--benji

"Bill Baxter" <wbaxter gmail.com> writes:

On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 "Tomas Lindquist Olsen" wrote
 Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers.
 The
 hack of using __dollar is bad (although it works).






 Agreed.

 It doesn't work for multiple dimensions. There should be an
 opDollar(uint
 dim) that gives the library information on which argument count it
 occured
 in. Consider:





 opDollar is the wrong choice of name.  The op* methods are - as a rule -
 named after the semantic function of the operator, rather than what the
 operator looks like.  For example, opMul not opAsterisk, opIndex not
 opSquareBrackets.  Consequently, opStar is already inconsistently named;
 I think one such is enough.  As for what the function to overload $
 should be called ... how about opEnd?

 Where did this conversation begin?  I can't seem to find any messages up
 the thread from the one I'm replying to now.

 Stewart.


 Since $ is used as a shortcut for for array.length, I'd say opLength is a
 better choice. Maybe I missed some of the discussion ...


 I'd agree with opEnd.  opLength is only a valid construct for arrays, where
 the slice indexes are based on how far into the container the element is.

 For example, if you wanted to 'slice' an AA, you would use 2 keys for the
 slice 'indexes', what if the keys are strings?


I'd say opSize, ala STL.  They got it right.  Should .size for arrays
too, not .length.  "Size" is a word that generalizes pretty well,
"length" is not.

Also don't forget about opStar!  It shoudn't be called that either.
opDeref is what it really wants to be.  :-)

[/dream mode off]
--bb

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 "Tomas Lindquist Olsen" wrote
 Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user 
 containers.
 The
 hack of using __dollar is bad (although it works).






 Agreed.

 It doesn't work for multiple dimensions. There should be an
 opDollar(uint
 dim) that gives the library information on which argument count it
 occured
 in. Consider:





 opDollar is the wrong choice of name.  The op* methods are - as a 
 rule -
 named after the semantic function of the operator, rather than what the
 operator looks like.  For example, opMul not opAsterisk, opIndex not
 opSquareBrackets.  Consequently, opStar is already inconsistently 
 named;
 I think one such is enough.  As for what the function to overload $
 should be called ... how about opEnd?

 Where did this conversation begin?  I can't seem to find any messages 
 up
 the thread from the one I'm replying to now.

 Stewart.


 Since $ is used as a shortcut for for array.length, I'd say opLength is 
 a
 better choice. Maybe I missed some of the discussion ...


 I'd agree with opEnd.  opLength is only a valid construct for arrays, 
 where
 the slice indexes are based on how far into the container the element is.

 For example, if you wanted to 'slice' an AA, you would use 2 keys for the
 slice 'indexes', what if the keys are strings?


 I'd say opSize, ala STL.  They got it right.  Should .size for arrays
 too, not .length.  "Size" is a word that generalizes pretty well,
 "length" is not.


size doesn't work for slices that don't use sequential integers as index. 
i.e. imagine a sorted map (such as tree map) slice:

TreeMap!(char[], char[]) tm;

// create a slice of the treemap

auto slice = tm["one".."two"];

Replace the second with 'length' or 'size', and it looks weird:

auto slice = tm["one"..length]
auto slice = tm["one"..size]

I much prefer 'end' or 'last'.  It reads natural.  From the "one" element to 
the end.

 Also don't forget about opStar!  It shoudn't be called that either.
 opDeref is what it really wants to be.  :-)

 [/dream mode off]


I agree with you there.

-Steve 

"Bill Baxter" <wbaxter gmail.com> writes:

On Fri, Sep 12, 2008 at 11:10 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 "Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
 For example, if you wanted to 'slice' an AA, you would use 2 keys for the
 slice 'indexes', what if the keys are strings?


 I'd say opSize, ala STL.  They got it right.  Should .size for arrays
 too, not .length.  "Size" is a word that generalizes pretty well,
 "length" is not.


 size doesn't work for slices that don't use sequential integers as index.
 i.e. imagine a sorted map (such as tree map) slice:

 TreeMap!(char[], char[]) tm;

 // create a slice of the treemap

 auto slice = tm["one".."two"];

 Replace the second with 'length' or 'size', and it looks weird:

 auto slice = tm["one"..length]
 auto slice = tm["one"..size]

 I much prefer 'end' or 'last'.  It reads natural.  From the "one" element to
 the end.


Ok, so you want to change the meaning of $ altogether from being a
number to something container dependent?

I guess that may generalize better...  But then shouldn't it evaluate
to an iterator?  Argh! :-)

--bb

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 11:10 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 "Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
 For example, if you wanted to 'slice' an AA, you would use 2 keys for 
 the
 slice 'indexes', what if the keys are strings?


 I'd say opSize, ala STL.  They got it right.  Should .size for arrays
 too, not .length.  "Size" is a word that generalizes pretty well,
 "length" is not.


 size doesn't work for slices that don't use sequential integers as index.
 i.e. imagine a sorted map (such as tree map) slice:

 TreeMap!(char[], char[]) tm;

 // create a slice of the treemap

 auto slice = tm["one".."two"];

 Replace the second with 'length' or 'size', and it looks weird:

 auto slice = tm["one"..length]
 auto slice = tm["one"..size]

 I much prefer 'end' or 'last'.  It reads natural.  From the "one" element 
 to
 the end.


 Ok, so you want to change the meaning of $ altogether from being a
 number to something container dependent?

 I guess that may generalize better...  But then shouldn't it evaluate
 to an iterator?  Argh! :-)


I think it should evaluate to the same type as you would specify as the 
first argument to the slice.  If that happens to be an integer, it's an 
integer, if it happens to be a string, it should be a string :)  If 
iterators are supported for a given container, it makes logical sense that 
slicing based on iterators should be supported.  I support slicing based on 
'cursors,' which are basically iterators, in dcollections (well, only for 
ArrayList now, but I plan to do it for LinkedList and the tree types).

opLength/opSize implies that it should ALWAYS be an integer.  'sall I'm 
sayin.

-Steve