On 10/10/2013 10:54 AM, Andrei Alexandrescu wrote:
On 10/10/13 12:18 AM, Walter Bright wrote:
On 10/9/2013 11:34 PM, Jacob Carlborg wrote:
On 2013-10-10 02:22, Sean Kelly wrote:
Only that this would have to be communicated to the user, since
moving data
later is problematic. Today, I think it's common to construct an
object as
unshared and then cast it.
What is the reason to not create it as "shared" in the first place?
1. Shared data cannot be passed to regular functions.
I don't understand this. If a function/method accepts "shared", then it can be
passed shared data.
I meant regular functions as in they are not typed as taking shared arguments.
Shared cannot be implicitly cast to unshared. I say regular because very, very
few functions are typed as accepting shared arguments.
2. Functions that create data structures would have to know in advance
that they'll be creating a shared object. I'm not so sure this would not
be an invasive change.
There is no other way around it. And this is not a change - it's fixing
something.
I'm not convinced of that at all.
3. Immutable data is implicitly shared. But it is not created immutable
- it is created as mutable data, then set to some state, then cast to
immutable.
That all must happen in the runtime, NOT in user code.
Andrei
