In article <bu8uhv$q7e$1@digitaldaemon.com>, Georg Wrede says...
>
>In article <bu8pmf$i6a$1@digitaldaemon.com>, J Anderson says...
>>
>>Georg Wrede wrote:
>>
>>> Hmm. This made me write a puzzle for everyone interested:
>
>> Can we answer here?  It's really very simple.
>
>Well, I wish nobody would publish the answer for a couple of days. Let people think about this at home during the weekend, and then, on Monday we could have some educated opinions about what the implications of this are!

A couple of days? weekend? think about this at home?

With that kind of efford by some people from here we
could finish DUI by then! both linux and windows...

;)

Ant

In article <bu9071$sro$1@digitaldaemon.com>, Ant says...
>
>>Let people think about this at home during the
>>weekend, and then, on Monday we could have some educated
>>opinions about what the implications of this are!
>
>A couple of days? weekend? think about this at home?
>
>With that kind of efford by some people from here we
>could finish DUI by then! both linux and windows...

LOL!

The solution to the puzzle is obvious, of course.

But more time should be used to consider if, and what
we might want to cange in D because of this. There are
many possibilities (of course starting with not changing
anything), and I'd like the discussion to be a bit more
profound on Monday.

In article <bu94ps$1470$1@digitaldaemon.com>, Georg Wrede says...
>
>In article <bu9071$sro$1@digitaldaemon.com>, Ant says...
>>
>>>Let people think about this at home during the
>>>weekend, and then, on Monday we could have some educated
>>>opinions about what the implications of this are!
>>
>>A couple of days? weekend? think about this at home?
>>
>>With that kind of efford by some people from here we
>>could finish DUI by then! both linux and windows...
>
>LOL!
>
>The solution to the puzzle is obvious, of course.
>
>But more time should be used to consider if, and what
>we might want to cange in D because of this. There are
>many possibilities (of course starting with not changing
>anything), and I'd like the discussion to be a bit more
>profound on Monday.
>
>


Monday's a holiday, I'll be in Palm Springs sipping margaritas by the pool. There will be no profond discussion from me that day. (As if there ever is.)

"The Lone Haranguer" <The_member@pathlink.com> wrote in message news:bu9c04$1g2i$1@digitaldaemon.com...
> In article <bu94ps$1470$1@digitaldaemon.com>, Georg Wrede says...
> >
> >In article <bu9071$sro$1@digitaldaemon.com>, Ant says...
> >>
> >>>Let people think about this at home during the
> >>>weekend, and then, on Monday we could have some educated
> >>>opinions about what the implications of this are!
> >>
> >>A couple of days? weekend? think about this at home?
> >>
> >>With that kind of efford by some people from here we
> >>could finish DUI by then! both linux and windows...
> >
> >LOL!
> >
> >The solution to the puzzle is obvious, of course.
> >
> >But more time should be used to consider if, and what
> >we might want to cange in D because of this. There are
> >many possibilities (of course starting with not changing
> >anything), and I'd like the discussion to be a bit more
> >profound on Monday.
> >
> >
>
>
> Monday's a holiday, I'll be in Palm Springs sipping margaritas by the
pool.
> There will be no profond discussion from me that day. (As if there ever
is.)

But, if you ingest sufficient margaritas there may be a "profond-ling" discussion, eh? :)

Hopefully there will be a bit of fondling on Sat and sun nights, yes.

>> Monday's a holiday, I'll be in Palm Springs sipping margaritas by the
>pool.
>> There will be no profond discussion from me that day. (As if there ever
>is.)
>
>But, if you ingest sufficient margaritas there may be a "profond-ling" discussion, eh? :)
>
>

Sorry for the insults.

This would be a bug then, i believe.

.length property of an array doesn't set pointer to 0. Or a zero-length array should always convert to false when comverted to boolean.

-eye


Robert wrote:
> He made a mistake then.
> Use
>     s = "";
> instead of
>     s.length = 0;
> Then AssertError will be thrown.
> 

In article <bukc2g$1650$1@digitaldaemon.com>, Ilya Minkov says...
>
>.length property of an array doesn't set pointer to 0. Or a zero-length array should always convert to false when comverted to boolean.

This is actually what made me post the String Puzzle here on Friday. http://www.digitalmars.com/drn-bin/wwwnews?D/21905

I'm really unhappy about the unobvious semantics of our current
"strings" (i.e. char[]).

While it is good to have character arrays, I think we should have a separate type for strings. That type would be used for everything where an explicit array of characters is not needed.

This would let us equate the null pointer with the empty string.
Append (~) null to foo should give foo. Length of cast(string)null
should be zero.

Nobody should ever be bitten by the natural mistake of taking the length of what he believes to be a string, and find out the value be different than the actual contents of the string. That is, the length property should behave differently than for character arrays, where it returns the allocation length (which most of the time is irrelevant to the string user anyway, and therefore getting the allocation length of a string should, at the most, be an intrinsic function).

Changing a string's length by assigning to length should be illegal! There should be a method for it. And that method should only allow making the string shorter! To make a string longer, you can always append spaces to it. Oh yes, and the string shortening method should return a new string!

This leads to the following:

- string slices should return new strings
- char[] slices should return references
- strings should be immutable
- strings should have value (not reference) semantics
- string slice as lvalue should operate on copy
- char[] slice as lvalue should operate on the original

If we want to keep the implicit string to char* conversion, then
probably strings should _both_ have a length property _and_ still
internally be represented with a \0 at the end? The cost of this
\0 in copying and other operations is negligible. Then we could
pass a D string to any C function, just like that. (The \0 at
the end should be an implementation thing, and you should not
be able to access it (by indexed access or slices or whatever.)

Since strings would not anymore be equal to character arrays, this would pave the way for new things. E.g. string slices could be considered to return characters. This is important for i18n.

I hope at least some of these thoughts see their way to D.

Hear hear!

<snip>
>While it is good to have character arrays, I think we should have a separate type for strings. That type would be used for everything where an explicit array of characters is not needed.
>
>This would let us equate the null pointer with the empty string.
>Append (~) null to foo should give foo. Length of cast(string)null
>should be zero.
>
>Nobody should ever be bitten by the natural mistake of taking the length of what he believes to be a string, and find out the value be different than the actual contents of the string. That is, the length property should behave differently than for character arrays, where it returns the allocation length (which most of the time is irrelevant to the string user anyway, and therefore getting the allocation length of a string should, at the most, be an intrinsic function).
>
>Changing a string's length by assigning to length should be illegal! There should be a method for it. And that method should only allow making the string shorter! To make a string longer, you can always append spaces to it. Oh yes, and the string shortening method should return a new string!
</snip>

Georg Wrede wrote:
> In article <bukc2g$1650$1@digitaldaemon.com>, Ilya Minkov says...
> 
>>.length property of an array doesn't set pointer to 0. Or a zero-length array should always convert to false when comverted to boolean.
> 
> 
> This is actually what made me post the String Puzzle here on Friday.
> http://www.digitalmars.com/drn-bin/wwwnews?D/21905
> 
> I'm really unhappy about the unobvious semantics of our current
> "strings" (i.e. char[]).
> 
> While it is good to have character arrays, I think we should have
> a separate type for strings. That type would be used for everything
> where an explicit array of characters is not needed. 

I could go either way.

> This would let us equate the null pointer with the empty string.
> Append (~) null to foo should give foo. Length of cast(string)null should be zero. 

Why is a null character so special? it's just another character. It was special in C for a reason, that's how C strings are.

> Nobody should ever be bitten by the natural mistake of taking the
> length of what he believes to be a string, and find out the value
> be different than the actual contents of the string. That is,
> the length property should behave differently than for character
> arrays, where it returns the allocation length (which most of
> the time is irrelevant to the string user anyway, and therefore
> getting the allocation length of a string should, at the most, be an intrinsic function).
> 
> Changing a string's length by assigning to length should be illegal! There should be a method for it. And that method should
> only allow making the string shorter! To make a string longer,
> you can always append spaces to it. Oh yes, and the string
> shortening method should return a new string!

I disagree; it's a convenience.

> This leads to the following:
> 
> - string slices should return new strings
> - char[] slices should return references
> - strings should be immutable
> - strings should have value (not reference) semantics
> - string slice as lvalue should operate on copy
> - char[] slice as lvalue should operate on the original

Sounds OK. I've wanted to have a "supplied buffer" function for each char[] function, so you can tell it to save the new string in a certain buffer instead of having it create a new one.

> If we want to keep the implicit string to char* conversion, then
> probably strings should _both_ have a length property _and_ still
> internally be represented with a \0 at the end? The cost of this
> \0 in copying and other operations is negligible. Then we could
> pass a D string to any C function, just like that. (The \0 at
> the end should be an implementation thing, and you should not
> be able to access it (by indexed access or slices or whatever.)

For a string type that isn't char[], I'd agree. I'd prefer that it only append the \0 at the time of casting to char*, cast overloads are good for this; I wonder why they aren't in D.

> Since strings would not anymore be equal to character arrays,
> this would pave the way for new things. E.g. string slices could
> be considered to return characters. This is important for i18n.
> 
> I hope at least some of these thoughts see their way to D.
> 
> 

Georg Wrede wrote:
> *snip*

We could just get the hell away from using 0 terminated strings.  D doesn't need the 0 terminator, unlike C.

 -- andy