D - two questions

These appeared when trying to actually write a simple
program in D, so somewhat more practical...

Is there a simple and (probably) fast way to add a
value at the end of a dynamic array? Documentation
doesn't say anything about that specifically, although
there are mentions of append() method when describing
strings. Does it work on any arrays? Is there a method
that removes last element of dynamic array?

Can "const" attribute be applied to function's return
type? An example:

    class Component
    {
        public const Component[] Children() { return children; }
        private Component[] children;
    }

As you can see, I want children[] to be readable, but not
writeable from outside of class (so that noone can add
child components but the component itself). Can it be
implemented this (or any other) way?

And an idea. I suggest that using enumerations when declaring
arrays would declare arrays with number of elements equal
to number of enumeration members:

    enum color { red, green, blue };
    bit[color] c;    // equal to bit[color.max].c;

Sometimes this can be useful, especially with bit arrays.
It also serves as at least partial emulation of Pascal sets.

Nov 13 2001

Russell Borogove <kaleja estarcion.com> writes:

Pavel \"EvilOne\" Minayev wrote:
 
 These appeared when trying to actually write a simple
 program in D, so somewhat more practical...
 
 Is there a simple and (probably) fast way to add a
 value at the end of a dynamic array? Documentation
 doesn't say anything about that specifically, although
 there are mentions of append() method when describing
 strings. Does it work on any arrays? Is there a method
 that removes last element of dynamic array?


I believe that Perl uses negative array indices to mean 
"back from the end", so array[-1] refers to the last 
valid element of the array. With bounds-controlled arrays,
I would think that negative indices would be free for 
this use, though it would occasionally turn an erroneous
index calculation into a valid-yet-incorrect access (or, 
looked at another way, it turns a bounded array into a 
partial circular array). I can see a lot of arguments 
against including this construct in D. :)

-RB

Nov 13 2001

"Walter" <walter digitalmars.com> writes:

"Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message
news:9srme1$331$1 digitaldaemon.com...
 Is there a simple and (probably) fast way to add a
 value at the end of a dynamic array?


I'm looking at:
    int a[];
    a[] ~= 3;

Is there a method
 that removes last element of dynamic array?


a = a[0..a.length - 1];

 Can "const" attribute be applied to function's return
 type? An example:


No. Const is a storage class in D, not a type modifier.


     class Component
     {
         public const Component[] Children() { return children; }
         private Component[] children;
     }

 As you can see, I want children[] to be readable, but not
 writeable from outside of class (so that noone can add
 child components but the component itself). Can it be
 implemented this (or any other) way?


The way to do that is to make it private and access it through get/set
member functions.


 And an idea. I suggest that using enumerations when declaring
 arrays would declare arrays with number of elements equal
 to number of enumeration members:

     enum color { red, green, blue };
     bit[color] c;    // equal to bit[color.max].c;

 Sometimes this can be useful, especially with bit arrays.
 It also serves as at least partial emulation of Pascal sets.


That's a great idea, but it conflicts with the syntax of associative arrays.

Nov 14 2001

"Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9sth7s$194b$1 digitaldaemon.com...

 I'm looking at:
     int a[];
     a[] ~= 3;


But wouldn't it interfere with the rule that:

    "In general, (a[n..m] op e) is defined as:

    for (i = n; i < m; i++)
        a[i] op e;"

Could lead to confusion...

Is there a method
 that removes last element of dynamic array?


 a = a[0..a.length - 1];


I believe it's not a special, optimized case recognized
by the compiler. I mean something to remove the element
without actually relocating the entire array - in other
words, something that simply decreases its "virtual" size
without actually changing anything.

 As you can see, I want children[] to be readable, but not
 writeable from outside of class (so that noone can add
 child components but the component itself). Can it be
 implemented this (or any other) way?


 The way to do that is to make it private and access it through get/set
 member functions.


But that's exactly what I did! I just want it to be indexed,
but not changed. And yes, I know that I could just write
some methods for that... but wouldn't it be better to provide
common syntax for all such cases? And since I can't overload
operator[], there is no way to do it other than expose the
array itself.

Maybe some special attribute similar to C/C++ const specially
for arrays & pointers?

 And an idea. I suggest that using enumerations when declaring
 arrays would declare arrays with number of elements equal
 to number of enumeration members:


 That's a great idea, but it conflicts with the syntax of associative



Oh, sorry, I missed the point. Maybe for bit arrays only (I mean,
associative bit arrays in D are not different from int ones... or
are they?)

Nov 14 2001

"Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:

 Maybe some special attribute similar to C/C++ const specially
 for arrays & pointers?


One more thing.

It seems quite strange to me that, while D provides
ways to declare variable passed to function as read-only
in that function, it doesn't have analogous construct
for what function returns...

Nov 14 2001

Aaron <arh14 cornell.edu> writes:

Well, I haven't checked out the D spec in a while, but the way Java does
it, and apparently the way D also does it, is that arrays are actually
mutable objects, so you can't just make them const.  Making them const
just means the *reference* cannot be modified, not the *contents* of the
reference.  There is no real way around this in Java except, as Walter
says, you make the array private, and write your own getters, and simply
don't provide setters.

Passing something *in* as read only, AFAICT, is simply equivalent to
pass-by-value instead of pass-by-reference.  I don't think variables
themselves should own these access flags - who knows what some method
down the road will want to do with a variable that at some point was
marked "read-only".  If you want something to be read only, the best
thing to do is simply to pass a copy instead of the actual thing (this
is already done for primitives, it just needs to be done for complex
objects).

Aaron

Pavel \"EvilOne\" Minayev wrote:
 
 Maybe some special attribute similar to C/C++ const specially
 for arrays & pointers?


 One more thing.
 
 It seems quite strange to me that, while D provides
 ways to declare variable passed to function as read-only
 in that function, it doesn't have analogous construct
 for what function returns...

Jan 11 2002

"Pavel Minayev" <evilone omen.ru> writes:

"Aaron" <arh14 cornell.edu> wrote in message
news:3C3EF365.24975587 cornell.edu...

 Passing something *in* as read only, AFAICT, is simply equivalent to
 pass-by-value instead of pass-by-reference.  I don't think variables


Yep, you are right here. "in" is the default, and means that
argument is passed by value.

 themselves should own these access flags - who knows what some method
 down the road will want to do with a variable that at some point was
 marked "read-only".  If you want something to be read only, the best
 thing to do is simply to pass a copy instead of the actual thing (this
 is already done for primitives, it just needs to be done for complex
 objects).


I have just forgotten that functions can return arrays and
associative arrays as well. With this, no problems.

Jan 11 2002

"Pavel Minayev" <evilone omen.ru> writes:

"Aaron" <arh14 cornell.edu> wrote in message
news:3C3EF365.24975587 cornell.edu...
 Well, I haven't checked out the D spec in a while, but the way Java does
 it, and apparently the way D also does it, is that arrays are actually
 mutable objects, so you can't just make them const.  Making them const
 just means the *reference* cannot be modified, not the *contents* of the
 reference.  There is no real way around this in Java except, as Walter
 says, you make the array private, and write your own getters, and simply
 don't provide setters.


Sorry, forgot one important thing...

I don't understand why arrays cannot be const? I just want to give a list
of controls to user, so he may index it, get its length etc, but isn't
able to add/delete/modify items. Of course this can be done with methods
(these won't be settors), like:

    Control item(int n) { return m_items[n]; }
    Control itemCount() { return m_items.length; }
    ...
    for (int i = 0; i < window.itemCount(); i++)
        window.item(i).visible = false;

However, it looks quite different from a typical D array.
With const arrays this would be absolute transparent to user:

    const Control[] items() { return m_items; }
    ...
    for (int i = 0; i < window.items.length; i++)
        window.item[i].visible = true;

There are some other properties that arrays have, for
example "dup"... methods are required to implement them
all, and it won't look like normal array.

Well anyhow Walter explained why he didn't made it in D,
so we have to live with it...

Jan 11 2002

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Pavel \"EvilOne\" Minayev wrote:

 "Walter" <walter digitalmars.com> wrote in message
 news:9sth7s$194b$1 digitaldaemon.com...

 I'm looking at:
     int a[];
     a[] ~= 3;


 But wouldn't it interfere with the rule that:

     "In general, (a[n..m] op e) is defined as:

     for (i = n; i < m; i++)
         a[i] op e;"

 Could lead to confusion...

Is there a method
 that removes last element of dynamic array?


 a = a[0..a.length - 1];


 I believe it's not a special, optimized case recognized
 by the compiler. I mean something to remove the element
 without actually relocating the entire array - in other
 words, something that simply decreases its "virtual" size
 without actually changing anything.


Why not

a.length--;

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Nov 14 2001

Russell Borogove <kaleja estarcion.com> writes:

Pavel \"EvilOne\" Minayev wrote:
 
 "Walter" <walter digitalmars.com> wrote in message
 news:9sth7s$194b$1 digitaldaemon.com...
Is there a method
 that removes last element of dynamic array?


 a = a[0..a.length - 1];


 I believe it's not a special, optimized case recognized
 by the compiler. I mean something to remove the element
 without actually relocating the entire array - in other
 words, something that simply decreases its "virtual" size
 without actually changing anything.


It's presumably as easy, or easier, for Walter to make the 
compiler recognize the a = a[0..X] case and optimize it as 
it would be for him to add syntax for a special case of same. 
If the initial index of the slice is computed, furthermore,
the slice generator could notice a computed zero at runtime 
that couldn't be guaranteed at compile time.[1]

Finally, it saves the programmer having to learn, remember, and 
appropriately-use a new feature. 


-RB

[1] In fact, if you want to get really ambitious, the internal
"start of allocated buffer" and "array-zero-base" pointers 
could actually be separate, and things like:

a = a[2..a.length];

could simply alter the length and zero-base pointers without 
doing a realloc (since saving two bytes hardly seems worth the 
time and potential fragmentation).

Nov 14 2001

"Walter" <walter digitalmars.com> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BF2B193.5F072C80 estarcion.com...
 [1] In fact, if you want to get really ambitious, the internal
 "start of allocated buffer" and "array-zero-base" pointers
 could actually be separate, and things like:

 a = a[2..a.length];

 could simply alter the length and zero-base pointers without
 doing a realloc (since saving two bytes hardly seems worth the
 time and potential fragmentation).


That's exactly how it does work. It's so much more efficient to do slicing
this way than the C way of copy and append a 0.

Nov 15 2001

Axel Kittenberger <axel dtone.org> writes:

 The way to do that is to make it private and access it through get/set
 member functions.


I don't see how get/set functions would help this, okay you do not need to 
return 'const obj **' (C speaking) an array of constant objects... but you 
would still need to return the object beeing requested by 
get_obj(object_number), like in your case 'obj *' (C speaking again), but 
how can I tell the caller without a const attribute in the sense of 
"contract programming" "please just look, but don't touch that object"?

- Axel
-- 
|D) http://www.dtone.org

Nov 14 2001

"Sean L. Palmer" <spalmer iname.com> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9sth7s$194b$1 digitaldaemon.com...
 "Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message
 news:9srme1$331$1 digitaldaemon.com...
 Is there a simple and (probably) fast way to add a
 value at the end of a dynamic array?


 I'm looking at:
     int a[];
     a[] ~= 3;


You sure you wouldn't it rather be more like this?:

a ~= 3;

It seems a, being the identifier representing the entire array, known to the
compiler to be dynamic, wouldn't need the []?

Why ~=, out of curiosity?  += isn't ambiguous in that context.  I don't see
what the problem is with people not looking up the declarations of variables
they're unfamiliar with.

Is there a method
 that removes last element of dynamic array?


 a = a[0..a.length - 1];


What's wrong with:

--a.size;

Oh... probably not writable.
or maybe:

a.resize(a.size-1);

No, too wordy.  Perhaps:

a--;

The "copying" syntax you suggest seems to leave it up to the compiler to
realize it can avoid the copy.  Debug builds could get very slow like that.

Sean

Nov 15 2001

Axel Kittenberger <axel dtone.org> writes:

 What's wrong with:
 
 --a.size;
 
 Oh... probably not writable.
 or maybe:
 
 a.resize(a.size-1);
 
 No, too wordy.  Perhaps:
 
 a--;


There is always a philsophic discussion how "decorated" a standard API 
should be, minimal (small is beautiful) or enlarged with a function for 
every possible task (even is reduntant.

I personally think the most intuative way would be

    a.shrink(1);

- Axel
-- 
|D) http://www.dtone.org

Nov 15 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Axel Kittenberger" <axel dtone.org> wrote in message
news:9t0b0e$che$1 digitaldaemon.com...

 I personally think the most intuative way would be

     a.shrink(1);


And a short form - a-- - then =)

Nov 15 2001

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9t016v$303d$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9sth7s$194b$1 digitaldaemon.com...
 "Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message
 news:9srme1$331$1 digitaldaemon.com...
 Is there a simple and (probably) fast way to add a
 value at the end of a dynamic array?


 I'm looking at:
     int a[];
     a[] ~= 3;


 You sure you wouldn't it rather be more like this?:

 a ~= 3;

 It seems a, being the identifier representing the entire array, known to


 compiler to be dynamic, wouldn't need the []?


You might be right. I'm going to have to think carefully about that.


 Why ~=, out of curiosity?  += isn't ambiguous in that context.  I don't


 what the problem is with people not looking up the declarations of


 they're unfamiliar with.


Overloading + with both addition and concatenation works well in most cases,
but there are a few maddening ones where it just is hopelessly ambiguous. I
decided that ~ as a binary operator would disambiguate it, and it will be
obvious by inspection if a concatenation or an addition is happening.


Is there a method
 that removes last element of dynamic array?


 a = a[0..a.length - 1];


 What's wrong with:

 --a.size;

 Oh... probably not writable.
 or maybe:

 a.resize(a.size-1);

 No, too wordy.  Perhaps:

 a--;

 The "copying" syntax you suggest seems to leave it up to the compiler to
 realize it can avoid the copy.  Debug builds could get very slow like



It's not a problem for the compiler to optimize away the copy.

Nov 15 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9t130m$1egm$3 digitaldaemon.com...

 Overloading + with both addition and concatenation works well in most


 but there are a few maddening ones where it just is hopelessly ambiguous.


 decided that ~ as a binary operator would disambiguate it, and it will be
 obvious by inspection if a concatenation or an addition is happening.


I believe that syntax proposed resolves this:

    a[] += 1;    // increase all elements of a by 1
    a += 1;      // add 1 at the end of a

Should be clear to everybody.

 It's not a problem for the compiler to optimize away the copy.


Still... a-- seems a good idea to me. Short and clear.

Nov 15 2001

"Sean L. Palmer" <spalmer iname.com> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9t130m$1egm$3 digitaldaemon.com...
 "Sean L. Palmer" <spalmer iname.com> wrote in message
 The "copying" syntax you suggest seems to leave it up to the compiler to
 realize it can avoid the copy.  Debug builds could get very slow like



 It's not a problem for the compiler to optimize away the copy.


But will it do so in a debug build?

Seems a debug build could at least do a little "safe" optimization such as
(a = a + b) ==> (a += b)

Sean

Nov 15 2001

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9t15tn$1j79$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9t130m$1egm$3 digitaldaemon.com...
 It's not a problem for the compiler to optimize away the copy.





Does it matter? Debug builds are for debugging the algorithms. You kind of
expect them to be bloated and slow <g>.

Nov 15 2001

Axel Kittenberger <axel dtone.org> writes:

Sean L. Palmer wrote:

 "Walter" <walter digitalmars.com> wrote in message
 news:9t130m$1egm$3 digitaldaemon.com...
 "Sean L. Palmer" <spalmer iname.com> wrote in message
 The "copying" syntax you suggest seems to leave it up to the compiler
 to
 realize it can avoid the copy.  Debug builds could get very slow like



 It's not a problem for the compiler to optimize away the copy.


 But will it do so in a debug build?
 
 Seems a debug build could at least do a little "safe" optimization such as
 (a = a + b) ==> (a += b)
 
 Sean


Take a look at the GNU toolchain if you want to. gdb and gcc are together 
perfectly able to directly debug optimized code, with gcc/gdb it is 
generally not necessary to turn of the optimizer to be able to debug, at 
last I've never had to. With the advantage you can debug the thing like it 
really is. The only time I personally encountered debug builds vs. real 
builds was in the micrsoft toolchain, and how often did it happen that the 
application runs perfectly as debug build, but crashes as release?

- Axel
-- 
|D) http://www.dtone.org

Nov 16 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9t130m$1egm$3 digitaldaemon.com...

 Why ~=, out of curiosity?  += isn't ambiguous in that context.  I don't


 what the problem is with people not looking up the declarations of


 they're unfamiliar with.


 Overloading + with both addition and concatenation works well in most


 but there are a few maddening ones where it just is hopelessly ambiguous.


 decided that ~ as a binary operator would disambiguate it, and it will be
 obvious by inspection if a concatenation or an addition is happening.


One more thing:

"D overloads the operators ... += for char and wchar arrays to
mean concatenate and append"

Since strings already work this way, why use different syntax
for other arrays?

Nov 15 2001

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t1aud$1qnf$1 digitaldaemon.com...
 "D overloads the operators ... += for char and wchar arrays to
 mean concatenate and append"


That's now no longer true. Looks like I missed fixing that in the doc.

Nov 15 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9t2kmn$16ah$2 digitaldaemon.com...

 That's now no longer true. Looks like I missed fixing that in the doc.


So now the ~= syntax is used on strings as well?

Kinda weird. If I didn't know that it means append, and
saw it for the first time, I would rather think of it
as of remove substring from a string... or something
like that. But definitely not append. Maybe &= then -
since BASIC already uses & for string concatenation?

Nov 16 2001

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Use PERL's syntax, since it's C-style and PERL is a common language that
includes string concatenation.

Use . as the array concatenation operator, and .= as the array append
opeator :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Nov 16 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF54058.8FF6F560 deming-os.org...

 Use PERL's syntax, since it's C-style and PERL is a common language that
 includes string concatenation.

 Use . as the array concatenation operator, and .= as the array append
 opeator :)


Noooooo!!!
(I hate Perl "."-concatenating!)

Nov 16 2001

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

???

I'd be interested why it's so bad.  I have only a little experience with PERL,
but it seemed to work fairly well as a syntax.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Nov 16 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF55275.C595CC1D deming-os.org...

 I'd be interested why it's so bad.  I have only a little experience with


 but it seemed to work fairly well as a syntax.


First of all, I don't see any "meaning" in it... using "+"
for concatenation seems most logical, "&" - "and" - is
not the worst choice as well. But definitely not "."

The second thing is that in D context, dot is already
used for other purpose. In fact, it could lead to confusion:

    char[] a;
    char length;
    a[].length;    // concatenate
    a.length;      // get length of a

Nov 16 2001

Russell Borogove <kaleja estarcion.com> writes:

Pavel Minayev wrote:
 
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BF55275.C595CC1D deming-os.org...
 
 I'd be interested why it's so bad.  I have only a little experience with


 but it seemed to work fairly well as a syntax.


 First of all, I don't see any "meaning" in it... using "+"
 for concatenation seems most logical, "&" - "and" - is
 not the worst choice as well. But definitely not "."
 
 The second thing is that in D context, dot is already
 used for other purpose. 


I'll just point out here that while both those arguments 
are valid in the D context, neither is valid in the Perl
context[1]. 

-RB

[1] Strings and numbers are automatically convertible, 
so that "1.0" + "2.0" = "3.0" (or maybe just "3" or "3."),
likewise &, so those aren't free for concatenation.

Perl generally uses {} or -> for object membership.

Nov 16 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BF58CF9.62606AF3 estarcion.com...

 First of all, I don't see any "meaning" in it... using "+"
 for concatenation seems most logical, "&" - "and" - is
 not the worst choice as well. But definitely not "."

 The second thing is that in D context, dot is already
 used for other purpose.


 I'll just point out here that while both those arguments
 are valid in the D context, neither is valid in the Perl
 context[1].


I know about the second (but we were talking about
D, no?). Still, I don't see any reason for using dot,
whether it is in Perl or in any other language. It's
not intuitive.

Nov 16 2001

"Walter" <walter digitalmars.com> writes:

My problem with . as concatenation is the . binary operator is already in
use, and I was afraid the . would be too small.

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF55275.C595CC1D deming-os.org...
 ???

 I'd be interested why it's so bad.  I have only a little experience with


 but it seemed to work fairly well as a syntax.

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Nov 16 2001

a <a b.c> writes:

Pavel Minayev wrote:
 
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BF54058.8FF6F560 deming-os.org...
 
 Use PERL's syntax, since it's C-style and PERL is a common language that
 includes string concatenation.

 Use . as the array concatenation operator, and .= as the array append
 opeator :)


 Noooooo!!!
 (I hate Perl "."-concatenating!)


Um, I second this.  I liked it enough in perl, but the timing is wrong
if perl is the justification.  Perl 6 is supposed to use the binary .
operator for member dereferencecs.  They are planning to have an _
operator I believe.  It will require white space before and after it.

Dan

Nov 21 2001

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t30p7$1rn5$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9t2kmn$16ah$2 digitaldaemon.com...
 That's now no longer true. Looks like I missed fixing that in the doc.




Yes.

 Kinda weird. If I didn't know that it means append, and
 saw it for the first time, I would rather think of it
 as of remove substring from a string... or something
 like that. But definitely not append. Maybe &= then -
 since BASIC already uses & for string concatenation?


D needed an operator token that was not already in use.

Nov 16 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9t4v38$13t3$3 digitaldaemon.com...

 That's now no longer true. Looks like I missed fixing that in the doc.




 Yes.


And what about string concatenation? Is "~" used for this
as well?

 D needed an operator token that was not already in use.


Why? You can't add anything to char in D (since it's not
integer), or ain't I right?

Nov 16 2001

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t53i1$16mq$2 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9t4v38$13t3$3 digitaldaemon.com...

 That's now no longer true. Looks like I missed fixing that in the








 So now the ~= syntax is used on strings as well?


 Yes.


 And what about string concatenation? Is "~" used for this
 as well?


As a binary operator, yes.

 D needed an operator token that was not already in use.


 integer), or ain't I right?


Sure you can add to chars. That's how to convert upper case to lower case!

Nov 17 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9t6hcs$24ek$1 digitaldaemon.com...

 As a binary operator, yes.


Oh my god... =)

My point here: don't introduce completely new things. Not
only C-heads will misunderstand you, but also most other
programmers - whose experience tells that ~ is a "not".
Use some existing solution. For example, Lua uses ..
for string concatenation, and I remember I saw it somewhere
else, so we have another candidate. And there might be
other suggestions here...

 Sure you can add to chars. That's how to convert upper case
 to lower case!


I always thought that the proper way to convert upper case to
lower case is to set or reset the appropriate bit, since it
works correctly even on already lower(upper)-cased chars...
so is it possible to use & and | on chars?

Nov 17 2001

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t6j40$25c8$1 digitaldaemon.com...
 My point here: don't introduce completely new things. Not
 only C-heads will misunderstand you, but also most other
 programmers - whose experience tells that ~ is a "not".
 Use some existing solution. For example, Lua uses ..
 for string concatenation, and I remember I saw it somewhere
 else, so we have another candidate. And there might be
 other suggestions here...


.. is already in use as the array slice operator. I'm not wedded to ~, it
just seems the best compromise.

 Sure you can add to chars. That's how to convert upper case
 to lower case!


 lower case is to set or reset the appropriate bit, since it
 works correctly even on already lower(upper)-cased chars...
 so is it possible to use & and | on chars?


Yes. All the arithmetic ops work on them.

Nov 18 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9t9hht$rtp$1 digitaldaemon.com...

 .. is already in use as the array slice operator. I'm not wedded to ~,
 it just seems the best compromise.


Maybe "$" then?

 Yes. All the arithmetic ops work on them.


Then what's the difference between char and ubyte?

Nov 18 2001

"Sean L. Palmer" <spalmer iname.com> writes:

Several printable ascii symbols are not used by D:   $,  #,   , \
(backslash), and ` (back quote)

I vote for # or ## to be the concatenation operator, since that is what it
did in the C preprocessor.  Fits, and it's fairly close to home as D is
based on C/C++.  Then append could be #= or ##= !

It'd probably be good to have one of these indicate an identifier or keyword
that is a compiler-dependent language extension.

Alternatively one of these could be allowed in a user-defined identifier.
This would be useful for instance in settor member functions and
constructors like so:

class Foo
{
  int a;
  int b;
  this(int  a, int  b) { a =  a; b =  b; }
  void seta(int  a) { a =  a; }
  void setb(int  b) { b =  b; }
}

Maybe   is too ugly.  But if _x is the form system identifiers take, then
user identifiers must use some other means to denote things such as x' =
f(x) etc.  Maybe backquote...  int x` = f(x);

I'm all for getting rid of case sensitivity in identifiers, it causes
problems in day-to-day programming.  Not hard problems usually, but annoying
sometimes...  mainly "I'm used to this capitalization style but the library
uses that capitalization style."  But with case sensitivity you can at least
do:  int X = f(x);

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9ta55f$1760$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9t9hht$rtp$1 digitaldaemon.com...

 .. is already in use as the array slice operator. I'm not wedded to ~,
 it just seems the best compromise.


 Maybe "$" then?

 Yes. All the arithmetic ops work on them.


 Then what's the difference between char and ubyte?

Nov 19 2001

Russell Borogove <kaleja estarcion.com> writes:

"Sean L. Palmer" wrote:
 
 Several printable ascii symbols are not used by D:   $,  #,   , \
 (backslash), and ` (back quote)
 
 I vote for # or ## to be the concatenation operator, since that is what it
 did in the C preprocessor.  Fits, and it's fairly close to home as D is
 based on C/C++.  Then append could be #= or ##= !


I second this nomination, preferring # for binary string concatenation 
and #= being appendature.  

-RB

Nov 19 2001

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9ta55f$1760$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9t9hht$rtp$1 digitaldaemon.com...
 .. is already in use as the array slice operator. I'm not wedded to ~,
 it just seems the best compromise.




Reasons?


 Yes. All the arithmetic ops work on them.


 Then what's the difference between char and ubyte?


You can overload them independently.

Nov 18 2001

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9tajkt$1gne$1 digitaldaemon.com...

 Maybe "$" then?


 Reasons?


It doesn't yet have any meaning in C/C++ context, so no
chance of understanding its wrong.

Nov 19 2001

D Programming

C/C++ Programming

Other

D - two questions