• Jason House (8/8) Jun 01 2009 Andrei has stated previously that unique was left out of the type system...
• Paul D. Anderson (6/20) Jun 01 2009 In the short time I was at the Kahili coffeehouse summit I heard Walter ...
• Robert Jacques (21/42) Jun 01 2009 1)
• Sean Kelly (8/14) Jun 01 2009 Move semantics. Just passing a unique value type to a function, a copy
• Jason House (3/19) Jun 01 2009 Why would copying occur? Can't a function simply pass it by reference an...
• Sean Kelly (3/15) Jun 01 2009 Technically, yes. I meant more from a language standpoint. A copy

Jason House <jason.james.house gmail.com> writes:

Andrei has stated previously that unique was left out of the type system
because it added little value to the const system. Now that shared and
multithreading are here, unique has more value.

I have two basic questions:

1. What would make unique difficult to add?

2. What benefits do you forsee?


Here are my thoughts:
1) Escape analysis - construction of unique objects must be careful with how
they manipulate their members. This would require scope parameters (AKA lent in
Bartosz's blog/literature). After construction, it may also be necessary to
update the manipulate the unique object while preserving its uniqueness.
Personally, I like the idea of scope by default, but I'm probably in the
minority.

2) Plugs a gaping hole in the type system. Even with shared added, I had a
moderate multi-threaded code base compile and run without use of shared or
casting. That boiled down to an inability to start threads without (silently)
subverting the type system. 
It's also possible to optimize operations on unique data in ways that one can't
do when a rogue write reference might exist somewhere.  That's not the same as
invariant, but it's similar. Unique can be implicitly cast to scope invariant. 

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

In the short time I was at the Kahili coffeehouse summit I heard Walter say
more than once that he was troubled by the idea of more transitive construction
types because he was afraid of the combinatorial explosion that would occur. 

And that was just adding 'unique'. Bartosz was trying to talk him into 'unique'
and 'lent'.

I don't know if Bartosz and Andrei and Walter came to any agreement -- they
seemed to be in three mutually exclusive frames of mind at the start anyway.

From my knothole I think unique and lent would be positive additions, even if
it does offend Walter's finer sensibilities!

Paul


Jason House Wrote:

 Andrei has stated previously that unique was left out of the type system
because it added little value to the const system. Now that shared and
multithreading are here, unique has more value.
 
 I have two basic questions:
 
 1. What would make unique difficult to add?
 
 2. What benefits do you forsee?
 
 
 Here are my thoughts:
 1) Escape analysis - construction of unique objects must be careful with how
they manipulate their members. This would require scope parameters (AKA lent in
Bartosz's blog/literature). After construction, it may also be necessary to
update the manipulate the unique object while preserving its uniqueness.
Personally, I like the idea of scope by default, but I'm probably in the
minority.
 
 2) Plugs a gaping hole in the type system. Even with shared added, I had a
moderate multi-threaded code base compile and run without use of shared or
casting. That boiled down to an inability to start threads without (silently)
subverting the type system. 
 It's also possible to optimize operations on unique data in ways that one
can't do when a rogue write reference might exist somewhere.  That's not the
same as invariant, but it's similar. Unique can be implicitly cast to scope
invariant. 

"Robert Jacques" <sandford jhu.edu> writes:

On Mon, 01 Jun 2009 19:16:55 -0400, Jason House  
<jason.james.house gmail.com> wrote:

 Andrei has stated previously that unique was left out of the type system  
 because it added little value to the const system. Now that shared and  
 multithreading are here, unique has more value.

 I have two basic questions:

 1. What would make unique difficult to add?

 2. What benefits do you forsee?


 Here are my thoughts:
 1) Escape analysis - construction of unique objects must be careful with  
 how they manipulate their members. This would require scope parameters  
 (AKA lent in Bartosz's blog/literature). After construction, it may also  
 be necessary to update the manipulate the unique object while preserving  
 its uniqueness. Personally, I like the idea of scope by default, but I'm  
 probably in the minority.

 2) Plugs a gaping hole in the type system. Even with shared added, I had  
 a moderate multi-threaded code base compile and run without use of  
 shared or casting. That boiled down to an inability to start threads  
 without (silently) subverting the type system.
 It's also possible to optimize operations on unique data in ways that  
 one can't do when a rogue write reference might exist somewhere.  That's  
 not the same as invariant, but it's similar. Unique can be implicitly  
 cast to scope invariant.

1)
Well, the difficulty I see, is that you can't just add unique.
When I think of unique, I generally think of it as being shallow - i.e.  
that object is unique, but it can contain references to non-unique objects  
(not-transitive). Though this makes construction, etc, easier, there are  
times you'd like to have non-unique members which are protected by the  
uniqueness of the parent. This adds a 'owned' type, which starts to run  
into Escape analysis issues.
Then there's ref unique, which is an odd duck: first the unique is moved  
into the function, and then on scope(exit) it is moved back out. This  
subtly comes into play with things like tasks/futures.
Of course, there's also 'lent', which allows unique to be used with a  
wider range of functions.

2)
To me, unique is all about performance. Shared can do all the same things,  
it just cost's taking a thin-lock to do so, which is pretty cheap. Having  
it as a type (instead of its current form as library template) does have  
some integration benefits with the lent system, but that's about it.

BTW, shared isn't implemented yet (beyond basic keyword recognition)

Sean Kelly <sean invisibleduck.org> writes:

Jason House wrote:
 Andrei has stated previously that unique was left out of the type system
because it added little value to the const system. Now that shared and
multithreading are here, unique has more value.
 
 I have two basic questions:
 
 1. What would make unique difficult to add?

Move semantics.  Just passing a unique value type to a function, a copy 
is performed.

 2. What benefits do you forsee?

Message passing could be done without needless copying and with a 
reasonable degree of safety.  I've done this before in C++ by storing 
the reference in a modified shared_ptr (so it can live in containers), 
then asserting is_unique() and transferring the reference to an auto_ptr 
when passing into the message.  Kind of messy, but it works well enough.

Jason House <jason.james.house gmail.com> writes:

Sean Kelly Wrote:

 Jason House wrote:
 Andrei has stated previously that unique was left out of the type system
because it added little value to the const system. Now that shared and
multithreading are here, unique has more value.
 
 I have two basic questions:
 
 1. What would make unique difficult to add?

 
 Move semantics.  Just passing a unique value type to a function, a copy 
 is performed.

Why would copying occur? Can't a function simply pass it by reference and then
zero out that register when done?

 
 2. What benefits do you forsee?

 
 Message passing could be done without needless copying and with a 
 reasonable degree of safety.  I've done this before in C++ by storing 
 the reference in a modified shared_ptr (so it can live in containers), 
 then asserting is_unique() and transferring the reference to an auto_ptr 
 when passing into the message.  Kind of messy, but it works well enough.

Sean Kelly <sean invisibleduck.org> writes:

Jason House wrote:
 Sean Kelly Wrote:
 
 Jason House wrote:
 Andrei has stated previously that unique was left out of the type system
because it added little value to the const system. Now that shared and
multithreading are here, unique has more value.

 I have two basic questions:

 1. What would make unique difficult to add?

 Move semantics.  Just passing a unique value type to a function, a copy 
 is performed.

 
 Why would copying occur? Can't a function simply pass it by reference and then
zero out that register when done?

Technically, yes.  I meant more from a language standpoint.  A copy 
theoretically occurs when returning a value from a function as well.