common types + type modifiers

Michel Fortin michel.fortin at michelf.com
Sun Jan 30 07:47:48 PST 2011


On 2011-01-29 20:09:11 -0500, Ellery Newcomer 
<ellery-newcomer at utulsa.edu> said:

> trying to wrap my head around shared,const,immutable (not inout yet, 
> though someday I'll need to figure out what it's supposed to do)
> 
> Currently, dmd doesn't exhibit a lot of consistency wrt the above, so 
> bear with me as I question every ____ing thing it does.
> 
> my [erroneous?] understanding of the modifiers:
> shared - many threads can see
> lack of shared - one thread can see plus some difference or other in 
> physical layout (of which I am mostly ignorant)
> immutable - nobody can mutate
> lack of immutable - anybody can mutate
> const - either immutable or mutable - you can't mutate because you 
> don't know which, but you also can't rely on it not mutating
> 
> shared(immutable(T)) == immutable(T) because who care who can see it if 
> nobody can mutate it
> 
> otherwise, shared(T) != T where T is not shared or immutable because T 
> might be mutable and then it matters who can see it and when
> 
> 
> What is the common type of two types with the same base T but different 
> modifiers?
> 
> My [erroneous?] [generic] reasoning:
> (notation - i under T1 means T1 == immutable(T), etc)
>         T1       :    T2  ->   ResultT
>         i              c          c        follows from my defs above
>         i              m          c        ditto
>         c              m          c        ditto
> 
> I think this is what dmd does. seems obvious.

Everything is correct up to here.


> what about shared?
> 
>         shared(U) : U -> ??     where U is not shared or immutable
> 
> the result is some sort of a 'maybe shared' - it definitely can't be U. 
> Can it be shared(U) ? I'm not sure about the semantics of tls, but it 
> seems like that would violate U's contract that only one thread can see 
> [and mutate] it.  So it seems to me that there is no common type of 
> shared(U) and U.

Indeed, U and shared(U) have no common type.


> unless it's acceptable to just make the mutability const. which would give:
> 
>         cs            m           cs
>         cs            c           cs
>         ms            m           cs
>         ms            c           cs

No, that doesn't work. There is no common type between shared and non-shared.


> otherwise, its a shared/shared or immutable/shared pair, so the result 
> type is shared, and the mutability is the same as for 
> unshared/unshared. which, come to think of it, will always be const. So 
> the result type will be const shared(T)
> 
> So that's my generic reasoning, which doesn't take the semantics of 
> subtypes, ease of use, etc, into account. here are some cases which I 
> suspect are wrong:
> 
> const(int)  :  int  ->  int
> const(int)  :  shared(int)  ->  int
> 
> and
> 
> shared(const(int*))  :  const(int*)  ->  const(int)*
> 
> 1) why can we do away with the constness of the pointer?
> 2) I think we should not do away with the sharedness of the pointer, 
> let alone of the element (shared is transitive too, isn't it?  it has 
> to be..)

About the constness of the pointer, you should only be able to do this 
when you make a copy of the pointer, as in:

	const(int*) a;
	const(int)* b = a;

There is no const violation here because pointer 'b' is a new variable, 
distinct of 'a'. The data it points to however is the same, so the 
'int' must stay const.

That said, shared(const(int*)) and const(int*) do not have a common 
type since one is shared and the other is not.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d-learn mailing list