June 08, 2004
<sings>For hes a jolly good fellow</sings>

In article <ca2v2q$1n14$1@digitaldaemon.com>, J C Calvarese says...
>
>J Anderson wrote:
>...
>> default arguments yay.
>
>Hip! Hip! Hooray!
>
>-- 
>Justin (a/k/a jcc7)
>http://jcc_7.tripod.com/d/



June 08, 2004
In article <ca37ns$24qn$1@digitaldaemon.com>, Walter says...
>
>
>"David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:ca2u66$1lui$1@digitaldaemon.com...
>> <*Wonders*> To you think Phobos.std.string could get a non-case sensitive
>> version of find (ifind) and rfind (irfind) added to it sometime in the
>near
>> future? It would be very useful (even if it just does ASCII). Thxs for
>your
>> reply in advance. :)
>
>Do you want to write one and donate it?
>
>
Walter: Sure, I'd be happy to donate the ifind() and irfind() functions I've
already written to solve my problem. Both have the normal (char[], char[])
parameters of find() and rfind(), but I've added a third int parameter that
allows setting the starting position for the search within the String, which
nomally defaults to a "0" when only the first two are passed in. But it's
nothing fancy compared to the code I've seen from others here in the forum.

So how would go about donating code toward making "D" better developer tool? :))

"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
June 08, 2004
A truly brilliant release. WOW! Thanks Walter.


I just need to reply to this:

><*Wonders*> Do you think Phobos.std.string could get a non-case sensitive
>version of find (ifind) and rfind (irfind) added to it sometime in the near
>future? It would be very useful (even if it just does ASCII). Thxs for your
>reply in advance. :)

Now that we have Hauke's Unichar stuff, we can do better than ASCII, we can do the whole of Unicode.

However - as a TEMPORARY MEASURE - we should do case-comparison on a character-by-character basis, just like you do for ASCII. This will get it right for something 99% of all a cases. (To catch the remaining cases we'd need the Unicode normalization and case folding algorithms, which no-one's implemented yet, but which we will have one day).

So long as we document that D's case-comparison rules CURRENTLY use simple casing instead of special casing, and do not YET handle normalization issues, no-one is going to complain, and - as you say - the ability to do case-insensitive stuff is very useful.

Jill


June 08, 2004
In article <ca3asj$2a3o$1@digitaldaemon.com>, Charlie says...

>Why not tolower() both of the strings ?

That won't cover all cases in Unicode, but there is a similar function designed
for just that purpose. It's called casefold(). In general, two normalized
strings a and b are considered case-insensitively-equal iff casefold(a) ==
casefold(b).

I just had a quick look through Hauke's unichar code and noticed, however, that charToCasefold() is not present? Hauke - any reason why you missed that one out? Did you assume it to be the same thing as charToLower()? It isn't, of course.

Jill



June 08, 2004
In article <ca3asj$2a3o$1@digitaldaemon.com>, Charlie says...

>Why not tolower() both of the strings ?

That won't cover all cases in Unicode, but there is a similar function designed
for just that purpose. It's called casefold(). In general, two normalized
strings a and b are considered case-insensitively-equal iff casefold(a) ==
casefold(b).

I just had a quick look through Hauke's unichar code and noticed, however, that charToCasefold() is not present? Hauke - any reason why you missed that one out? Did you assume it to be the same thing as charToLower()? It isn't, of course.

Jill



June 08, 2004
Post it and let's have a look!


June 08, 2004
Binary operator overloading: for consistency, I would suggest replacing opCmp() with opLt(), opLe(), etc and to split opEquals() into opEquals() and opNotEquals() (or is the latter a typo in the documentation?)


June 08, 2004
On Tue, 08 Jun 2004 08:01:35 +0200, Jeroen van Bemmel wrote:

> Binary operator overloading: for consistency, I would suggest replacing opCmp() with opLt(), opLe(), etc and to split opEquals() into opEquals() and opNotEquals() (or is the latter a typo in the documentation?)

I think this was discussed before.
I think the rational is on the web documentation

Ant

June 08, 2004
This is the best release of D I've seen so far. It's brilliant. Well done. Jill


June 08, 2004
"Walter" <newshound@digitalmars.com> wrote in message news:ca2nau$1ath$1@digitaldaemon.com...
> It's now possible to do assymmetrical operator overloads with commutative operators like +.
> 
> And it's now possible to create a << stream operator overloading in D. Not that I endorse such a use of operator overloading for non-arithmetic purposes, but it's now possible (without doing free operator functions or needing ADL, either!).
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 

WOW! Walter you are really making it harder and harder to complain about the language!!! :)

Just a little question:
a.. The Expression within an array's brackets is now an AssignExpression (meaning that commas are no longer allowed).

Could this mean that rectangular arrays are coming in some future? :)