"Anders F Björklund" <afb@algonet.se> wrote in message news:db4863$17dt$1@digitaldaemon.com...
> Regan Heath wrote:
>
>> I think the default case would be mutable, eg
>>   char[] foo() {}
>>
>> returns a mutable array, however:
>>   readonly char[] foo() {}
>>
>> returns an immutable one.
>
> I think the default case should be immutable...
> AFAIK, it already is - although not enforced ?
>
> If nothing else, "const char *" is boring to type,
> and I don't think "readonly char[]" would be less.
>
> Better to have readwrite/mutable for "the other 10%",
> than having a readonly/immutable applied to "most" ?
>
> --anders

char[#]  is a bit better than readonly char[], huh? :)))

Other choices  : C99 trigraphs style
char[<>],  char[:], etc.

Regan Heath wrote:

> True. Which is why I chose 'mutable' as the default, I think it's more  common, thus less typing. You obviously disagree. Only code analysis will  tell us for sure, and then I suspect different types/areas will show a  different result.

Actually, I think "immutable" is the most common case for parameters.
As for local variables, there it is pretty common to want "mutable" ?

Too bad that the C++ usage of the keywords "const" and "mutable" have
muddied the waters enough to make any discussion about it confusing...

Meanwhile, it seems it's back to the usual warnings on the wrapping:
"use caution.contents might be hot.slippery when wet.immutable inside"

 >> Better to have readwrite/mutable for "the other 10%",
>> than having a readonly/immutable applied to "most" ?
> 
> I disagree with 10%, and "most", obviously.

Obviously. I don't have any numbers to back it up - I just meant it as
in the 90/10 rule... (a.k.a. 80/20 rule, etc). As in common/uncommon ?

It also assumes that you can do a _whole lot_ of manipulation with
immutable strings, just not change the referenced contents directly.

i.e. you could still concat strings and use functions to convert it
to upper case and so and so forth. (by creating new immutable copies)

Actual syntax could probably still need some design work, though.
(but I'm supposed to be on summer vacation soon, so I'll leave it)

--anders

Andrew Fedoniouk wrote:

> char[#]  is a bit better than readonly char[], huh? :)))

Actually I thought you said "char #[]", maybe you changed it...

Alternative:
The argument "char[inout]" (contents) would be pretty similar to
"inout char[]" (reference), but still a bit hard to decipher ?

(that is: the first would be like "const char*", and the second
would be like "char* const"

BTW;
The "readonly" attribute was only a less-loaded const alternative.
But it seems like it still burdened by all the Const Correctness...

--anders

On Thu, 14 Jul 2005 09:46:35 +0200, Anders F Björklund <afb@algonet.se> wrote:

> Regan Heath wrote:
>
>> True. Which is why I chose 'mutable' as the default, I think it's more  common, thus less typing. You obviously disagree. Only code analysis will  tell us for sure, and then I suspect different types/areas will show a  different result.
>
> Actually, I think "immutable" is the most common case for parameters.

I agree. I was talking about return values being mutable.

> As for local variables, there it is pretty common to want "mutable" ?

Yep. That's what I said too.

> Too bad that the C++ usage of the keywords "const" and "mutable" have
> muddied the waters enough to make any discussion about it confusing...

You may have miss-read what I wrote?

> Meanwhile, it seems it's back to the usual warnings on the wrapping:
> "use caution.contents might be hot.slippery when wet.immutable inside"

LOL.

>   >> Better to have readwrite/mutable for "the other 10%",
>>> than having a readonly/immutable applied to "most" ?
>>  I disagree with 10%, and "most", obviously.
>
> Obviously. I don't have any numbers to back it up - I just meant it as
> in the 90/10 rule... (a.k.a. 80/20 rule, etc). As in common/uncommon ?
>
> It also assumes that you can do a _whole lot_ of manipulation with
> immutable strings, just not change the referenced contents directly.
>
> i.e. you could still concat strings and use functions to convert it
> to upper case and so and so forth. (by creating new immutable copies)
>
> Actual syntax could probably still need some design work, though.
> (but I'm supposed to be on summer vacation soon, so I'll leave it)

Here is a summary of what I expect to be common.

return values: mutable
local variables: mutable
parameters: immutable

Regan

Regan Heath wrote:

>> Too bad that the C++ usage of the keywords "const" and "mutable" have
>> muddied the waters enough to make any discussion about it confusing...
> 
> You may have miss-read what I wrote?

Could be, we seem to be in agreement. (now it's "just the details")

> Here is a summary of what I expect to be common.
> 
> return values: mutable
> local variables: mutable
> parameters: immutable

I think e.g. "char[] toString()" should return an immutable string.
String literals should definitely be immutable, as well. (local too)

But I do need to write more D code, in order to test this out fully.

--anders

On Thu, 14 Jul 2005 11:25:03 +0200, Anders F Björklund <afb@algonet.se> wrote:
> Regan Heath wrote:
>
>>> Too bad that the C++ usage of the keywords "const" and "mutable" have
>>> muddied the waters enough to make any discussion about it confusing...
>>  You may have miss-read what I wrote?
>
> Could be, we seem to be in agreement. (now it's "just the details")
>
>> Here is a summary of what I expect to be common.
>>  return values: mutable
>> local variables: mutable
>> parameters: immutable
>
> I think e.g. "char[] toString()" should return an immutable string.

Maybe, maybe not, whatever is most common.

> String literals should definitely be immutable, as well. (local too)

Yeah, I agree. You can always .dup for a mutable one.

> But I do need to write more D code, in order to test this out fully.

In cases where it's a class method the return value is more likely to be immutable, for a normal function (unless it's returning static data, as toString does) it's more likely to be mutable, or so I reasoned.

Regan

Andrew Fedoniouk wrote:

> 
> Thanks, Brad. Extremely cool.
> Concept car looked nice but was not moving :)
> 
> BTW: on Windows you would use VirtualAlloc for that.
> With the same result, though.
> 
> And try to imagine that you are passing something
> like root node of some XML DOM into function
> designed to return second child node....
> 
> 
:) That's pretty much what I thought.  But it was worth a shot to see if something could be done - we do after all have an MMU so we should try to use it :)

Brad

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:db12la$17to$1@digitaldaemon.com...
> Except one: I just don't understand - how contract programming
> helps to increase memory safety.
> Currently D's DbC features allows you only check for NULL.
>
> Did I miss something in principle?

You can write the contracts to test for anything you want, not just NULL.

"Mike Capp" <mike.capp@gmail.com> wrote in message news:db40ld$11b1$1@digitaldaemon.com...
> I'm still convinced that GC is massive overkill for local-scoped class
variables
> and (to a lesser extent) simple value-like class members. C++'s default
stack
> allocation is a far better story than D on this front.

"simple value-like class" object instances in D are called structs and are allocated on the stack.

"Walter" <newshound@digitalmars.com> wrote in message news:db63at$31dn$2@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:db12la$17to$1@digitaldaemon.com...
>> Except one: I just don't understand - how contract programming
>> helps to increase memory safety.
>> Currently D's DbC features allows you only check for NULL.
>>
>> Did I miss something in principle?
>
> You can write the contracts to test for anything you want, not just NULL.
>
>

Walter, it was all about memory safety and DbC.

The only one test available for DbC (runtime DbC test, sic!) now is to test
on NULL pointer.
What else I can do to verify is it safe to write into this memory or not?
Preferably in compile/design time.

Andrew.