In article <duluq5$11ki$1@digitaldaemon.com>, Kevin Bealer says...
>
>Also, this is not full "C++ const", only parameter passing and const methods, which seems to be the most popular parts of the const idea. It seems like it should require more syntax that C++, but it only takes a small amount.
>
>
>When working with types like "int", use "in" - const is not too much of an issue here.
>
>The same is true for struct, it gets copied in, which is fine for small structs.  For larger structs, you might want to pass by "in *", i.e. use "in Foo *".  You can modify this technique to use struct, for that see the last item in the numbered list at the end.
>
>
>For classes, the issue is that the pointer will not be modified with the "in" convention, but the values in the class may be.
>
> // "Problem" code

Oops .. this seems to have been cut off.. apparently a single "." causes this reader to destroy email.  I'll post the other 80% of the post again tonight.

Kevin

In article <dunjv7$kpj$1@digitaldaemon.com>, Kevin Bealer says...
>
>Oops .. this seems to have been cut off.. apparently a single "." causes this reader to destroy email.  I'll post the other 80% of the post again tonight.
>

For what it's worth, the SMTP and NNTP protocols* both use the sequence "\r\n.\r\n" as meaning "end of data".  Depending on the quality of your newsreader**, it might not be aware of this and won't filter it out of your post.  Having that embedded gives you an unexpectedly truncated message, just like you have here.


* - For those not in the know, these are for email (outbound) and usenet
respectively
** - Was it the newsreader on digitalmars.com?


- EricAnderton at yahoo

>>
>> Let's say we have two declarations:
>>
>> T[] and readonly T[]
>>
>> These two describe two different types - they have two different sets of methods:
>>
>> T[] has opSliceAssign and opIndexAssign.
>> in contrary readonly T[] has no such methods.
>>
>> This is why they are two distinct types. And it is highly desirable that
>> they will be treated
>> as types and not as any sort of contracts. Think about template
>> instantiation, static if's and so on.
>
> Is it necessary that there are two distinct types? I feel it would be enough, if there was one type with two sets of methods, one of which could always be called, and the other only through a non-readonly reference.
>
> Are there any benefits to having two distinct types?

Logically it is one type - region  from ptr and up to ptr+length
But in this two cases it has different set of operations.
You may *interpret* it as different types.

readonly is a filter - it filters out all mutators from base type.

static if( T[] has(method) opSliceAssign) -> compile-time-true and
static if( readonly T[] has(method) opSliceAssign ) -> compile-time-false

Andrew Fedoniouk.
http://terrainformatica.com

In article <dunl76$m25$1@digitaldaemon.com>, pragma says...
>
>In article <dunjv7$kpj$1@digitaldaemon.com>, Kevin Bealer says...
>>
>>Oops .. this seems to have been cut off.. apparently a single "." causes this reader to destroy email.  I'll post the other 80% of the post again tonight.
>>
>
>For what it's worth, the SMTP and NNTP protocols* both use the sequence "\r\n.\r\n" as meaning "end of data".  Depending on the quality of your newsreader**, it might not be aware of this and won't filter it out of your post.  Having that embedded gives you an unexpectedly truncated message, just like you have here.
>
>
>* - For those not in the know, these are for email (outbound) and usenet
>respectively
>** - Was it the newsreader on digitalmars.com?
>
>
>- EricAnderton at yahoo

Yes it was - this "\n.\n" concept seems vaguely and anciently familiar.  I'm posting again with a different "please dont also lose indentation" character.

Kevin

In article <dun85t$33t$1@digitaldaemon.com>, Kevin Bealer says...
>
>In article <dumhec$21bq$1@digitaldaemon.com>, xs0 says...
>>
>>Kevin Bealer wrote:
>..
>>OK, this is like the 5000th post I've read regarding const correctness and related issues in D. Can we really not come to some kind of an agreement on what would be best? I'm sure if there's a consensus about a solution, Walter will eventually implement it.
>>
>..
>>- conceptually, each class definition (say Foo : Bar) produces two new types, "readonly Foo : readonly Bar" and "Foo : readonly Foo, Bar", the first of which only contains readonly methods, while the second contains all others. That makes it trivial to do verification and overloading, and has a nice feature that there is no need to actually compile the readonly version, as all verification is done statically, so there is no increase in code size etc.
>
>This sounds like it has nearly the same properties as what I'm proposing.  The main difference seems to be that you can designate methods as only usable in the readonly case.  (I'm not sure what that would be useful for, though.)
>
>Notice that the inheritance hierarchy described in the paragraph above is the *same* as what I wrote.

But that part got cut off (sorry bout that), you can find it in the second thread by me with the same title. - Kevin

>My point, if you read my post, was that you don't need to introduce new keywords or syntax.  If you want or need the division between const/nonconst for a particular type, it can be written in existing D.
>
>Kevin
>
>