www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - readonly storage class

reply Benjamin Thaut <code benjamin-thaut.de> writes:
While typing D code I usually come across the problem that neither const 
nor immutable describe the usage pattern of the memory I'm currently 
working on 100%. Sometimes I have immutable data that has been shared 
among threads that I want to pass to a function. Then I have some const 
data that I want to pass to the same function. Currently you don't have 
any other choice but to write that function two times. But the function 
itself does not need the "extended" properties of const or immutable:

const: can be casted back to mutable
immutable: can be implicitly shared among threads

The only thing the function cares about is, that it will not change the 
data passed to it. It would be kind of nice to have a thrid storage 
class "readonly". It can not be casted back to mutable and it can not be 
implicitly shared among threads, but both const and immutable implicitly 
convert to readonly, because both of these storage classes lose one of 
their properties during conversion. That way you only have to write the 
function once and can pass both const and immutable data to it.

Just an idea, comments and critics welcome.

-- 
Kind Regards
Benjamin Thaut
Apr 08 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/08/2012 11:16 AM, Benjamin Thaut wrote:

 While typing D code I usually come across the problem that neither const
 nor immutable describe the usage pattern of the memory I'm currently
 working on 100%. Sometimes I have immutable data that has been shared
 among threads that I want to pass to a function. Then I have some const
 data that I want to pass to the same function. Currently you don't have
 any other choice but to write that function two times. But the function
 itself does not need the "extended" properties of const or immutable:

 const: can be casted back to mutable


It cannot.


 immutable: can be implicitly shared among threads

 The only thing the function cares about is, that it will not change the
 data passed to it. It would be kind of nice to have a thrid storage
 class "readonly". It can not be casted back to mutable and it can not be
 implicitly shared among threads, but both const and immutable implicitly
 convert to readonly, because both of these storage classes lose one of
 their properties during conversion. That way you only have to write the
 function once and can pass both const and immutable data to it.

 Just an idea, comments and critics welcome.


I don't get the problem. Can you demonstrate the issue with an example?
Apr 08 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote:

 While typing D code I usually come across the problem that neither const
 nor immutable describe the usage pattern of the memory I'm currently
 working on 100%. Sometimes I have immutable data that has been shared
 among threads that I want to pass to a function. Then I have some const
 data that I want to pass to the same function. Currently you don't have
 any other choice but to write that function two times. But the function
 itself does not need the "extended" properties of const or immutable:
 
 const: can be casted back to mutable
 immutable: can be implicitly shared among threads
 
 The only thing the function cares about is, that it will not change the
 data passed to it. It would be kind of nice to have a thrid storage
 class "readonly". It can not be casted back to mutable and it can not be
 implicitly shared among threads, but both const and immutable implicitly
 convert to readonly, because both of these storage classes lose one of
 their properties during conversion. That way you only have to write the
 function once and can pass both const and immutable data to it.
 
 Just an idea, comments and critics welcome.


I would point out that casting const to mutable and then altering the variable 
is subverting the type system. The compiler does not support casting away 
either const or immutable to alter _anything_. So, as far as the type system 
is concerned, if you want a function that takes both const and immutable, it 
should take const.

Now, you _can_ cast away const and alter a variable if you're careful, but 
you're subverting the type system when you do so and throwing away any 
guarantees that the compiler gives you. It's far from safe.

Given that casting away const on a variable and then mutating is subverting 
the type system and thate therefore the compiler is free to assume that you 
will never do it, I don't see what your idea of readonly would buy us. It's 
the same as const.

- Jonathan M Davis
Apr 08 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 08.04.2012 11:28, schrieb Jonathan M Davis:

 On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote:

 While typing D code I usually come across the problem that neither const
 nor immutable describe the usage pattern of the memory I'm currently
 working on 100%. Sometimes I have immutable data that has been shared
 among threads that I want to pass to a function. Then I have some const
 data that I want to pass to the same function. Currently you don't have
 any other choice but to write that function two times. But the function
 itself does not need the "extended" properties of const or immutable:

 const: can be casted back to mutable
 immutable: can be implicitly shared among threads

 The only thing the function cares about is, that it will not change the
 data passed to it. It would be kind of nice to have a thrid storage
 class "readonly". It can not be casted back to mutable and it can not be
 implicitly shared among threads, but both const and immutable implicitly
 convert to readonly, because both of these storage classes lose one of
 their properties during conversion. That way you only have to write the
 function once and can pass both const and immutable data to it.

 Just an idea, comments and critics welcome.


 I would point out that casting const to mutable and then altering the variable
 is subverting the type system. The compiler does not support casting away
 either const or immutable to alter _anything_. So, as far as the type system
 is concerned, if you want a function that takes both const and immutable, it
 should take const.

 Now, you _can_ cast away const and alter a variable if you're careful, but
 you're subverting the type system when you do so and throwing away any
 guarantees that the compiler gives you. It's far from safe.

 Given that casting away const on a variable and then mutating is subverting
 the type system and thate therefore the compiler is free to assume that you
 will never do it, I don't see what your idea of readonly would buy us. It's
 the same as const.

 - Jonathan M Davis


I'll come up with a example.
But if what you say is true, why is immutable not implicitly convertible 
to const?

-- 
Kind Regards
Benjamin Thaut
Apr 08 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 08, 2012 11:39:03 Benjamin Thaut wrote:

 I'll come up with a example.
 But if what you say is true, why is immutable not implicitly convertible
 to const?


It _is_ implictly convertible to const.

- Jonathan M Davis
Apr 08 2012
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 08 Apr 2012 11:39:03 +0200, Benjamin Thaut  
<code benjamin-thaut.de> wrote:


 Am 08.04.2012 11:28, schrieb Jonathan M Davis:

 On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote:

 While typing D code I usually come across the problem that neither  
 const
 nor immutable describe the usage pattern of the memory I'm currently
 working on 100%. Sometimes I have immutable data that has been shared
 among threads that I want to pass to a function. Then I have some const
 data that I want to pass to the same function. Currently you don't have
 any other choice but to write that function two times. But the function
 itself does not need the "extended" properties of const or immutable:

 const: can be casted back to mutable
 immutable: can be implicitly shared among threads

 The only thing the function cares about is, that it will not change the
 data passed to it. It would be kind of nice to have a thrid storage
 class "readonly". It can not be casted back to mutable and it can not  
 be
 implicitly shared among threads, but both const and immutable  
 implicitly
 convert to readonly, because both of these storage classes lose one of
 their properties during conversion. That way you only have to write the
 function once and can pass both const and immutable data to it.

 Just an idea, comments and critics welcome.


 I would point out that casting const to mutable and then altering the  
 variable
 is subverting the type system. The compiler does not support casting  
 away
 either const or immutable to alter _anything_. So, as far as the type  
 system
 is concerned, if you want a function that takes both const and  
 immutable, it
 should take const.

 Now, you _can_ cast away const and alter a variable if you're careful,  
 but
 you're subverting the type system when you do so and throwing away any
 guarantees that the compiler gives you. It's far from safe.

 Given that casting away const on a variable and then mutating is  
 subverting
 the type system and thate therefore the compiler is free to assume that  
 you
 will never do it, I don't see what your idea of readonly would buy us.  
 It's
 the same as const.

 - Jonathan M Davis


 I'll come up with a example.
 But if what you say is true, why is immutable not implicitly convertible  
 to const?


It is.
Apr 08 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 08.04.2012 11:49, schrieb Simen Kjaeraas:

 On Sun, 08 Apr 2012 11:39:03 +0200, Benjamin Thaut
 <code benjamin-thaut.de> wrote:


 Am 08.04.2012 11:28, schrieb Jonathan M Davis:

 On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote:

 While typing D code I usually come across the problem that neither
 const
 nor immutable describe the usage pattern of the memory I'm currently
 working on 100%. Sometimes I have immutable data that has been shared
 among threads that I want to pass to a function. Then I have some const
 data that I want to pass to the same function. Currently you don't have
 any other choice but to write that function two times. But the function
 itself does not need the "extended" properties of const or immutable:

 const: can be casted back to mutable
 immutable: can be implicitly shared among threads

 The only thing the function cares about is, that it will not change the
 data passed to it. It would be kind of nice to have a thrid storage
 class "readonly". It can not be casted back to mutable and it can
 not be
 implicitly shared among threads, but both const and immutable
 implicitly
 convert to readonly, because both of these storage classes lose one of
 their properties during conversion. That way you only have to write the
 function once and can pass both const and immutable data to it.

 Just an idea, comments and critics welcome.


 I would point out that casting const to mutable and then altering the
 variable
 is subverting the type system. The compiler does not support casting
 away
 either const or immutable to alter _anything_. So, as far as the type
 system
 is concerned, if you want a function that takes both const and
 immutable, it
 should take const.

 Now, you _can_ cast away const and alter a variable if you're
 careful, but
 you're subverting the type system when you do so and throwing away any
 guarantees that the compiler gives you. It's far from safe.

 Given that casting away const on a variable and then mutating is
 subverting
 the type system and thate therefore the compiler is free to assume
 that you
 will never do it, I don't see what your idea of readonly would buy
 us. It's
 the same as const.

 - Jonathan M Davis


 I'll come up with a example.
 But if what you say is true, why is immutable not implicitly
 convertible to const?


 It is.


Thanks, then this is a misunderstanding on my side, and this topic is 
irrelevant. But what about calling const methods on immutable objects?

-- 
Kind Regards
Benjamin Thaut
Apr 08 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/08/2012 06:09 PM, Benjamin Thaut wrote:

 Am 08.04.2012 11:49, schrieb Simen Kjaeraas:

 On Sun, 08 Apr 2012 11:39:03 +0200, Benjamin Thaut
 <code benjamin-thaut.de> wrote:

 I'll come up with a example.
 But if what you say is true, why is immutable not implicitly
 convertible to const?


 It is.


 Thanks, then this is a misunderstanding on my side, and this topic is
 irrelevant. But what about calling const methods on immutable objects?


That works.
Apr 08 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 08, 2012 at 06:09:48PM +0200, Benjamin Thaut wrote:
[...]

 Thanks, then this is a misunderstanding on my side, and this topic is
 irrelevant. But what about calling const methods on immutable objects?


[...]

Basically, the way const/immutable works is:

	           const
	          /     \
	unqualified     immutable

Both unqualified and immutable implicitly convert to const, but not the
other way around (except in certain special cases, like copying ints).


T

-- 
People walk. Computers run.
Apr 08 2012
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Benjamin Thaut wrote:

 The only thing the function cares about is, that it will not change the
 data passed to it. It would be kind of nice to have a thrid storage
 class "readonly".


Const is really a "readonly" view of data. I think that immutable should 
be named const, and const should be named readonly, so they won't cause 
confusion.

If you need a function that don't change data just mark parameters as 
const. All mutable, const and immutable types are implicitly convertible 
to const.


 It can not be casted back to mutable and it can not be
 implicitly shared among threads, but both const and immutable implicitly
 convert to readonly, because both of these storage classes lose one of
 their properties during conversion. That way you only have to write the
 function once and can pass both const and immutable data to it.


Yes, this is how const (as "readonly") works. If you think about 
readonly, use const. The only drawback are the names.
Apr 08 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Piotr Szturmaj wrote:

 If you need a function that don't change data just mark parameters as


                             ^ doesn't
Apr 08 2012