While I understand both your position and Joe's one, I think that it is good if
in the Swift community at large, outside of this mailing list itself, more
thought was given also to the side effects / losses in moving everything over
to value types over references (one could have said with careful use of copy
constructors and other solutions reference types can be tamed so why bother
with value type renaissance? People seemed to make a lot of production code
before...) and how those can and should be tamed.
Value types and the impact on performance (copies were advertised as almost
free in Dave's talks but even when implementing CoW smartly like you have done
with Array, Dictionary, etc... this still may mean surprising large copies
happening at times some users may not expect them to be).
Regardless of the outcome I still see debate on this and putting yesterday's
values to the test of today's data and knowledge pragmatic and it should not be
seen as raining on the language's parade :).
Sorry for the rant-ish nature of my reply.
Sent from my iPhone
> On 4 Aug 2016, at 04:46, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> On Aug 3, 2016, at 7:57 PM, Joe Groff <jgr...@apple.com> wrote:
>>>>>
>>>>> a. We indirect automatically based on some heuristic, as an
>>>>> optimization.
>>>
>>> I weakly disagree with this, because it is important that we provide a
>>> predictable model. I’d rather the user get what they write, and tell
>>> people to write ‘indirect’ as a performance tuning option. “Too magic” is
>>> bad.
>>
>> I think 'indirect' structs with a heuristic default are important to the way
>> people are writing Swift in practice. We've seen many users fully invest in
>> value semantics types, because they wants the benefits of isolated state,
>> without appreciating the code size and performance impacts. Furthermore,
>> implementing 'indirect' by hand is a lot of boilerplate. Putting
>> indirectness entirely in users' hands feels to me a lot like the "value if
>> word sized, const& if struct" heuristics C++ makes you internalize, since
>> there are similar heuristics where 'indirect' is almost always a win in
>> Swift too.
>
> I understand with much of your motivation, but I still disagree with your
> conclusion. I see this as exactly analogous to the situation and discussion
> when we added indirect to enums. At the time, some argued for a magic model
> where the compiler figured out what to do in the most common “obvious” cases.
>
>
> We agreed to use our current model though because:
> 1) Better to be explicit about allocations & indirection that implicit.
> 2) The compiler can guide the user in the “obvious” case to add the keyword
> with a fixit, preserving the discoverability / ease of use.
> 3) When indirection is necessary, there are choices to make about where the
> best place to do it is.
> 4) In the most common case, the “boilerplate” is a single “indirect” keyword
> added to the enum decl itself. In the less common case, you want the
> “boilerplate” so that you know where the indirections are happening.
>
> Overall, I think this model has worked well for enums and I’m still very
> happy with it. If you generalize it to structs, you also have to consider
> that this should be part of a larger model that includes better support for
> COW. I think it would be really unfortunate to “magically indirect” struct,
> when the right answer may actually be to COW them instead. I’d rather have a
> model where someone can use:
>
> // simple, predictable, always inline, slow in some cases.
> struct S1 { … }
>
> And then upgrade to one of:
>
> indirect struct S2 {…}
> cow struct S3 { … }
>
> Depending on the structure of their data. In any case, to reiterate, this
> really isn’t the time to have this debate, since it is clearly outside of
> stage 1.
>
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
