June 30, 2005
On Thu, 30 Jun 2005 02:06:12 -0400, Andrew Fedoniouk <news@terrainformatica.com> wrote:

> I would like to discuss one of my previous ideas again
> as it seems it was lost in the fire.
>
> I think below is the best compromise we can get. In fact
> as more I am looking on it as more I am sure that it
> not even compromise - it is "well done immutables".
>
> Idea is to extend typesystem with a new type: immutable (const, readonly)
> array and pointer.
>
> Proposed notation of immutable array type is as:
>
>      typename#[]
>
> Proposed notation of immutable pointer is as:
>
>      typename#*
>

I don't like it. Not just the syntax. I think immutable is so common that it should be the default. Right now we have to enforce it ourselves using COW. I don't have much of a problem with it but it seems many others do.

What if arrays and pointers were immutable by default? The only way to make something mutable is to use a mutable keyword. I think it would be much more productive and sounds a lot more relaxing than specifying immutable. There would have to be a way to force something that is immutable to be mutable (?). Perhaps using cast(mutable char[]) for char[]. Here is an example:


char[] foo = "hi"; // Good, immutable.
mutable char[] bar = new char[30];
char[] baz = bar; // Mutable to immutable.
mutable char[] bat = "hey"; // ERROR, string literal is immutable.
mutable char[] qux = cast(mutable char[])bar; // Force immutable to mutable. Not recommended.


It would break a lot of existing code, but I believe supporting the current style could still be supported using -deprecated.

- Chris
June 30, 2005
Vathix wrote:
> On Thu, 30 Jun 2005 02:06:12 -0400, Andrew Fedoniouk  <news@terrainformatica.com> wrote:
<snip>
> I don't like it. Not just the syntax. I think immutable is so common that  it should be the default. Right now we have to enforce it ourselves using  COW. I don't have much of a problem with it but it seems many others do.
<snip>
> - Chris

Would you still fall into the category of "we need _something_ to protect immutable data"?

I think I might start a voting thread to see who need/want this feeture :)

Brad
June 30, 2005
On Thu, 30 Jun 2005 13:40:26 -0400, Brad Beveridge <brad@somewhere.net> wrote:

> Would you still fall into the category of "we need _something_ to protect immutable data"?

No, but I'm willing to compromise.
June 30, 2005
What is the difference between that and C++'s const as a type modifier?

C++:
    typename const *
Proposal:
    typename # *


June 30, 2005
Walter wrote:

> What is the difference between that and C++'s const as a type modifier?
> 
> C++:
>     typename const *
> Proposal:
>     typename # *

Or the other proposal, "readonly", seeing as how const is overloaded...
(or the newly proposed variant thereof, which seems to be "immutable")

BTW;
There seems to be a lot of weird syntax lately: [$], !is and now char#[]


Another note:
There was an old suggestion (I think) that an explicit "in" would mean
readonly for the array contents too, and not just for the array pointer.

But it's a bit "unclear" for declarations, I think ? "in typename *"

--anders
June 30, 2005
Hi,

>Or the other proposal, "readonly", seeing as how const is overloaded... (or the newly proposed variant thereof, which seems to be "immutable")

The shorter the better, in my opinion. I prefer const or # over the other ones.

>BTW; There seems to be a lot of weird syntax lately: [$], !is and now char#[]

I agree, but I don't think it's a bad thing at all. The more the merrier, I say. Oh, and what is [$]? I've never seen that one before...

>Another note:
>There was an old suggestion (I think) that an explicit "in" would mean
>readonly for the array contents too, and not just for the array pointer.

I like this a lot. This is the way it should be, IMHO, by default at all times; at least the explicit "in" would give us the option to enforce it.

I can't decide which one I like better, the explicit in or immutability; either one would be a great improvement. I guess both would be even better?

Cheers,
--AJG.

=======================
I sync, therefore I am.
June 30, 2005
AJG wrote:

> Oh, and what is [$]? I've never seen that one before...

"length", for arrays. As in this "remove":
array = array[0 .. i-1] ~ array[i+1 .. $];

--anders
June 30, 2005
On Thu, 30 Jun 2005 11:19:38 -0700, Walter <newshound@digitalmars.com> wrote:
> What is the difference between that and C++'s const as a type modifier?
>
> C++:
>     typename const *
> Proposal:
>     typename # *

Nothing, which is why I prefer the idea I've been bandying (sp?) around here for the past month. Please read carefully this is _not_ the same thing.

A readonly compile time, and perhaps also runtime (disabled for -release) readonly bit flag for all variables.

Initialised to 'false'.

Set to 'true' in the presence of "readonly" as a type modifier.

Set to 'true' when passed as an 'in' parameter.

Compiler errors on all operations that mutate a readonly flagged variable.

Example usage:

class Foo {
  char[] data;
  readonly char[] get() { return data; }
}

void foo(inout char[] data) { data[0] = 'a'; }

Foo f = new Foo();
char[] p = f.get();
p[0] = 'a'; //error cannot mutate readonly
foo(p); //error passing readonly as mutable

void foo(char[] data) { data[0] = 'a'; } //error cannot mutate readonly

IMPORTANT: this does not create a seperate distinct type, "readonly char[]" is not a different type to "char[]" it's the same type with it's readonly flag set to 'true'.

The reason this is important is that it stops this situation...

char[] s;
..s used as temp var here..
readonly char[] p = f.get();
s = p; //error s is not readonly

Which is just plain irritating. People typically solve the above by casting the readonly away. Not good. In the above 's's readonly flag is set on assignment, it becomes readonly.

The readonly flag would be set to false when passed as 'out', or on assignment to a rhs which has readonly=false (including null).

A runtime flag is required for cases like:

char[] p = test ? some_string : f.get();
p[1] = 'd'; //is 'p' readonly if some_string isn't?

where the compiler cannot tell at compile time.

The runtime flag would be present in every single variable, disabled by -release and/or it's own compile time flag (perhaps disabled by default like -unittest)

Regan
June 30, 2005
"Walter" <newshound@digitalmars.com> wrote in message news:da1d5u$1kdf$1@digitaldaemon.com...
> What is the difference between that and C++'s const as a type modifier?
>
> C++:
>    typename const *
> Proposal:
>    typename # *
>
>

typename # * is eqiuvalent of

C++'s
    const typename *
-or-
    typename const *

It is a 'mutable pointer to immutable data.'

I think that proposed singular form

typename #*

where '#' means 'no = '  is a bit better.
But again it is a personal matter.

Andrew.



July 01, 2005
Awesome, thanks. I use length a lot, so $ is great.

Anybody have any concerns about this usage?:

// Easy way to get last element.
int lastItem = someArray[--$];

Cheers,
--AJG.


In article <da1q3p$26jr$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>AJG wrote:
>
>> Oh, and what is [$]? I've never seen that one before...
>
>"length", for arrays. As in this "remove":
>array = array[0 .. i-1] ~ array[i+1 .. $];
>
>--anders

========================
if (!sin) throw rock[0];