Jump to page: 1 2
Thread overview
readonly storage class
Apr 08, 2012
Benjamin Thaut
Apr 08, 2012
Timon Gehr
Apr 08, 2012
Jonathan M Davis
Apr 08, 2012
Benjamin Thaut
Apr 08, 2012
Jonathan M Davis
Apr 08, 2012
Simen Kjaeraas
Apr 08, 2012
Benjamin Thaut
Apr 08, 2012
Timon Gehr
Apr 08, 2012
H. S. Teoh
Apr 08, 2012
Piotr Szturmaj
Apr 08, 2012
Piotr Szturmaj
April 08, 2012
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
April 08, 2012
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?
April 08, 2012
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
April 08, 2012
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
April 08, 2012
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
April 08, 2012
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.
April 08, 2012
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.

April 08, 2012
Piotr Szturmaj wrote:
> If you need a function that don't change data just mark parameters as
                            ^ doesn't
April 08, 2012
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
April 08, 2012
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.
« First   ‹ Prev
1 2