"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?

"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!
> 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?

Yes. All the arithmetic ops work on them.

"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?

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?

"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?

Reasons?


> > Yes. All the arithmetic ops work on them.
>
> Then what's the difference between char and ubyte?

You can overload them independently.

"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.

"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

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

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...

"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.