Janice Caron wrote:
> On 05/04/2008, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> 
>> In fact, to get technical,
>>it should be:
>>pure int f(invariant Class c);
> 
> 
> I wondered about that.
> 
> It seems to me that if /all/ of the parameters, /and/ the return value
> /must/ be invariant (or implicitly castable to invariant, e.g. int)
> then couldn't
> 
>     pure R f(A a, B b, C c, D d)
> 
> be syntactic sugar for
> 
>     pure invariant(R) f(invariant(A) a, invariant(B) b, invariant(C)
> c, invariant(D) d)
> 
> ? (Especially what with "invariant" being a nine-letter keyword and all!)

(OT) This shows how misleading the "transitive const" moniker is.

Obviously, we should name the topic "recursive invariant".

Steven Schveighoffer wrote:

> Sorry.  Usually, to convince "the world" of an opinion, you must argue continuously with the single doubter.  Otherwise, it looks like you give in :)

This being a public forum (as Forum in the antique Greece), i.e. a place for debating, it's your duty to do that. That was the whole point of having these forums.

And ever since then, those who had no clue, as well as most of the audience in general, could then rely on (or at least successfully bet on) the guy or opinion that wins in the end. (Not of course right every time, but often enough.)

(( rest of excellent and lucid post not repeated here ))

Thanks!

Lars Ivar Igesund wrote:
> Walter Bright wrote:
>> Invariant strings have turned out to be a resounding success (and I was
>> very, very skeptical of that initially). I suspect that more and more
>> programs will gravitate towards using invariant as people get more used
>> to the idea. I know my programs will.
> 
> Do you have any references to this resounding success?
> 

I think that what Walter said ("Invariant strings have turned out to be a resounding success") is quite obvious to be true. But note that he said "invariant strings", and not "invariant" by itself.
In other words, what he said does not imply that D's invariant/const system has been a resounding success.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> Sure, but static class members are *not* part of the transitive closure state of the object. They're just global variables.
>>
>> Neither are mutable member variables.
> 
> How can a member not be a member of the state of an object?

If you have a tree node, you can have a member that is a link to the parent node. While the child nodes are considered part of the state of the tree node, the parent node is not. (That's why it's conceptually an optional member in such structure, unlike the child nodes).

Another example is a GUI widget object that has a link (aka a member) to it's Display (an class that represents the display properties where the GUI object will be rendered). The Display member is not part of the state of the GUI widget. It makes perfect sense to want const (or invariant) to restrict it's effect only to the other members of the GUI widget, but not the display member (and others which are not part of the logical state of the object).

It all comes down to the familiar concept of composition vs. aggregation.

I can give a link to an academic paper that details what I've mentioned, if you're still not convinced.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>> Invariant strings have turned out to be a resounding success (and I was
>>> very, very skeptical of that initially). I suspect that more and more
>>> programs will gravitate towards using invariant as people get more used
>>> to the idea. I know my programs will.
>>
>> Do you have any references to this resounding success?
>>
> 
> I think that what Walter said ("Invariant strings have turned out to be a resounding success") is quite obvious to be true.

A success in what way?  And what do they achieve that could not have been achieved via plain old const strings?


Sean

On 27/04/2008, Sean Kelly <sean@invisibleduck.org> wrote:
> what do they achieve that could not have been
> achieved via plain old const strings?

In a word: (OK - in three words): Copy On Write.

For example, one could write a function

    string escape(string s);

which escaped certain characters (by preceding them with '\' or whatever). Because s is an array of invariant chars, if nothing needs to be escaped, the function is able to return s.

This would not be possible with "plain old const strings". To illustrate, suppose the declaration of the function had been

    const(char)[] escape(const(char)[] s);

Then:

    char[] s = "fixed".dup;

    auto t = escape(s);
    assert(t == "fixed");

    s[0] = 'm';
    assert(t == "fixed"); /* FAILS */


With invariant, it just works.

Janice Caron wrote:
> On 27/04/2008, Sean Kelly <sean@invisibleduck.org> wrote:
>> what do they achieve that could not have been
>> achieved via plain old const strings?
> 
> In a word: (OK - in three words): Copy On Write.
> 
> For example, one could write a function
> 
>     string escape(string s);
> 
> which escaped certain characters (by preceding them with '\' or
> whatever). Because s is an array of invariant chars, if nothing needs
> to be escaped, the function is able to return s.

So this is predicated on the idea that the optimal strategy is to assume that library functions will not actually need to make any changes the majority of the time, and that they do COW internally.  Fair enough.  I agree that this makes it a clear win for Phobos, which is designed around this assumption.


Sean

Sean Kelly wrote:
> So this is predicated on the idea that the optimal strategy is to assume that library functions will not actually need to make any changes the majority of the time, and that they do COW internally.  Fair enough.  I agree that this makes it a clear win for Phobos, which is designed around this assumption.

It turns out to be a very natural way of writing string code. And yes, I was surprised to discover that in-place string modification turned out to be rare. Most operations are slicing/concatenating, which work just fine on invariant strings.

Walter Bright wrote:
> Most operations are slicing/concatenating, which work just fine on
> invariant strings.

Correct me if I'm wrong, but if you want to concatenate two invariant strings, you have to allocate a new buffer. Isn't that a possible speed penalty compared to regular strings? Since if you use regular strings you can allocate one of the two string buffers beforehand big enough and save this allocation, with invariant strings you don't have this option.

...or to rephrase my question, wouldn't a StringBuilder Class without invariant strings be much faster?

LLAP,
Sascha

Sascha Katzner wrote:

> Walter Bright wrote:
>> Most operations are slicing/concatenating, which work just fine on invariant strings.
> 
> Correct me if I'm wrong, but if you want to concatenate two invariant strings, you have to allocate a new buffer. Isn't that a possible speed penalty compared to regular strings?

Indeed it is, and this is the main reason for Tango being so damn fast at text processing.

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