Bill Baxter wrote:

... snip ...

> 
> That stuff like this compiles and seems to work is why we really need to make at least one alternative version of cast.  One would be for relative safe run-of-the-mill casts, like casting float to int, or casting Object to some class (and checking for null),  and the other category would be for dangerous big red flags kind of things like the above.  Using the run-of-the-mill cast in the above situation would not be allowed.

Amen to that !!!

On 28/04/2008, Sean Kelly <sean@invisibleduck.org> wrote:
> Can you explain this in light of Steven's 'scoped const' proposal?

I meant that non-invariant versions would have to make a copy, but the invariant version sometimes wouldn't. That means they can't share the same code.


>     string bufI = "HELLO";
>     char[] bufM = "HELLO".dup;
>     const(char)[] bufC = bufM;
>
>     const(char)[] retC = toupper( bufC ); // return value is const - ok
>
>     bufM[0] = 'J';
>     assert( retC[0] == 'J' );

Why would that assert hold? I would expect toupper(char[]) to have to return a copy precisely in order to /prevent/ that problem. What am I missing?

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Janice Caron wrote:
> > If there's enough interest, and if Walter approves, I could certainly kickstart std.stringbuffer. Is that the right way to go? What do people think?
> What it will do is provide a useful solution for those who really want to use mutable strings. I bet that, though, after a while they'll evolve to eschew it in favor of immutable strings. It's easier than arguing about it <g>.

I do agree with the notion that the majority of operations performed
on strings in a typical application do not modify the string in place.
However, in performance-oriented server applications, is it very
common to hold and reuse a mutable buffer between calls to avoid
the const of reallocation.  Assuming that references to this data are
passed around during the processing of a client request I would
fully expect the surrounding code to have no need to mutate the data.
However, because this is a reusable buffer, invariant is not a safe option
because the contents of the buffer will change for each request.  What
I would be inclined to do here is use const references to reflect this.

I've been thinking a lot about const and invariant recently and while invariant strings seem quite handy for test code and the like, I have not been able to think of a single production application where I would actually be able to use them for the bulk of my string data, for the reason mentioned above.  Rather, I would expect to use 'const' everywhere because what I generally care about is preventing a caller or callee from changing the contents of my data.  As for indicating ownership, the following rule generally suffices:

    char[] getData(); // result is mutable -- ownership is transferred
    const(char)[] getData(); // result is const -- ownership not transferred

What I love about Steven's "scoped const" proposal is that it would allow me to write a single instance of a library function that would work equally well with any data, and the function would communicate its behavior within the syntax.  Add "scoped const" to D 1.0 plus the ability to use 'const' in all the places it can be used in D 2.0 and I'd be a happy camper.  Bonus points for eliminating storage of static const (ie ROM-able) data and dropping support for anonymous enum altogether.


Sean

P.S. The utility of 'invariant' for multiprogramming is a separate issue.  I actually think it's unnecessary there as well, but don't want the discussion to get off track by addressing this at all.  I'm merely adding this note so no one will bring it up in response to what I said above.

"Walter Bright" wrote
> p9e883002@sneakemail.com wrote:
>> So, that's two copies of the string, plus a slice, plus an extra method call to achieve what used to be achievable in place on the original string. Which is now immutable, but I'll never need it again. Of course, on these short 1-off strings it doesn't matter a hoot. But when the strings are 200 to 500 characters a pop and there are 20,000,000 of them. It matters.
>>
>> Did I suggest this was an optimisation?
>
> You bring up a good point.
>
> On a tiny example such as yours, where you can see everything that is going on at a glance, such as where strings come from and where they are going, there isn't any point to immutable strings. You're right about that.
>
> The problems start happening as the complexity rises. Strings get passed around, stored, modified, etc. It's real easy to lose track of who owns a string, who else has references to the string, who has rights to change the string and who doesn't.
>
> For example, you're changing the char[][] passed in to main(). What if one of those strings is a literal in the read-only data section?
>
> So what happens is code starts defensively making copies of the string "just in case." I'll argue that in a complex program, you'll actually wind up making far more copies than you will with invariant strings.

I agree that immutable strings can be valuable.  That's why I think it's important to have a version of toupper that uses invariant strings because you can make more assumptions about when to make copies.  But why shouldn't there be a version that does the same thing with mutable or const strings? Why should a developer be forced to always use invariant strings when the optimizations and multithreading benefits that come with only using invariant strings may not be more important for a particular program than being able to modify a string?  I should still be able to use toupper on mutable strings as well...

-Steve

Steven Schveighoffer wrote:
> I agree that immutable strings can be valuable.  That's why I think it's important to have a version of toupper that uses invariant strings because you can make more assumptions about when to make copies.  But why shouldn't there be a version that does the same thing with mutable or const strings? Why should a developer be forced to always use invariant strings when the optimizations and multithreading benefits that come with only using invariant strings may not be more important for a particular program than being able to modify a string?  I should still be able to use toupper on mutable strings as well...

That's why I agreed with Janice on making a stringbuffer module that operates on mutable strings. It's easier than arguing about it, and it doesn't hurt to have such a package. And I suspect that after using it for a while, people will naturally evolve towards using all invariant strings.

Sean Kelly wrote:

> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> Janice Caron wrote:
>> > If there's enough interest, and if Walter approves, I could certainly kickstart std.stringbuffer. Is that the right way to go? What do people think?
>> What it will do is provide a useful solution for those who really want to use mutable strings. I bet that, though, after a while they'll evolve to eschew it in favor of immutable strings. It's easier than arguing about it <g>.
> 
> I do agree with the notion that the majority of operations performed
> on strings in a typical application do not modify the string in place.
> However, in performance-oriented server applications, is it very
> common to hold and reuse a mutable buffer between calls to avoid
> the const of reallocation.

Indeed, in the application I'm currently writing at work, there is not a single heap allocation after the startup phase. And it cannot be called trivial in any sense.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Walter Bright wrote:

> Steven Schveighoffer wrote:
>> I agree that immutable strings can be valuable.  That's why I think it's
>> important to have a version of toupper that uses invariant strings
>> because
>> you can make more assumptions about when to make copies.  But why
>> shouldn't there be a version that does the same thing with mutable or
>> const strings? Why should a developer be forced to always use invariant
>> strings when the optimizations and multithreading benefits that come with
>> only using invariant strings may not be more important for a particular
>> program than
>> being able to modify a string?  I should still be able to use toupper on
>> mutable strings as well...
> 
> That's why I agreed with Janice on making a stringbuffer module that operates on mutable strings. It's easier than arguing about it, and it doesn't hurt to have such a package. And I suspect that after using it for a while, people will naturally evolve towards using all invariant strings.

After working with Java for quite some time, I have naturally drifted from using invariant strings to stringbuffers.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

On 28/04/2008, Walter Bright <newshound1@digitalmars.com> wrote:
>  What it will do is provide a useful solution for those who really want to
> use mutable strings. I bet that, though, after a while they'll evolve to
> eschew it in favor of immutable strings.

I'm inclined to agree with the prediction - but even so, wouldn't that be a good thing? I mean, if it keeps people on board with D2 who might otherwise have run away, then that's good, right? And if those people later realise they can do more with immutable strings, then that's good too, right?

Just a thought.

Lars Ivar Igesund wrote:
> After working with Java for quite some time, I have naturally drifted from
> using invariant strings to stringbuffers.

Java strings lack slicing, so they're crippled anyway. I believe that slicing is one of those paradigm-shifting features, so I am not making an irrelevant point.

Janice Caron wrote:
> On 28/04/2008, Walter Bright <newshound1@digitalmars.com> wrote:
>>  What it will do is provide a useful solution for those who really want to
>> use mutable strings. I bet that, though, after a while they'll evolve to
>> eschew it in favor of immutable strings.
> 
> I'm inclined to agree with the prediction - but even so, wouldn't that
> be a good thing? I mean, if it keeps people on board with D2 who might
> otherwise have run away, then that's good, right? And if those people
> later realise they can do more with immutable strings, then that's
> good too, right?

I think we're in agreement.