IMO the ledger isn’t just about access control, it’s also about having a
convenient (and guaranteed correct, due compiler enforcement) place to see
where the rest of your class is defined.
I’m +1 on the ledger and partial classes in general. I think extensions serving
the dual purpose of exte
> On Oct 30, 2017, at 6:38 PM, Adam Kemp via swift-evolution
> wrote:
>
>
>
>> On Oct 30, 2017, at 2:23 PM, Mike Kluev wrote:
>>
>> On 30 October 2017 at 19:49, Adam Kemp wrote:
>>
>> How do you know there’s not an extension in this file without looking? If
>> you don’t know then you h
Even if separating code into modules was an effortless process “internal" would
still not be the right access modifier because you would have to make a
sub-module for every class in a class hierarchy which defined new “protected”
members. So we would need some near-effortless process for creatin
Internal is the best choice available at the moment but I wouldn’t call it the
“right” choice. Languages with the concept of classes often have a “protected”
scope with means “visible within this class and subclasses”. In Swift that
could mean “visible within this class, subclasses, and extensio
As a "regular user" I wholeheartedly agree with everything Robert just said.
Syntactic consistency between function parameters and closure parameters is a
big win for usability and discoverability.
I actually did not know that it was possible to destructure tuples in closure
arguments before th
