This is an intriguing proposal. There are parts I like, and parts that I
will have to think about more before drawing an opinion.
Personally, I would like to see public classes be inheritable, public
protocols be conformable, and public enums be switchable, unless specified
otherwise. However I wi
(1) It seems odd to use scope as both an access control modifier alone and as a
function-like attribute. Perhaps something like access(set, scope) would be
better than scope(set). As it is, we’re conflating scope with meaning
visibility and lexical scope—I found that very confusing.
I like the i
Just scanned it, but my first impression is: LOVE IT!
IMO this is the way to go.
Though some of the details will no doubt be improved. I will read it in more
depth coming WE.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
General impression is positive in case shortcuts (private, bulblic) still
remain for the most common use cases.
On Thu, 2 Mar 2017 at 21:58 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
> I’ve been continuing to think about how to provide clear and consistent
> semantics
> On Mar 3, 2017, at 3:19 AM, Adrian Zubarev via swift-evolution
> wrote:
>
> (1) It seems odd to use scope as both an access control modifier alone and as
> a function-like attribute. Perhaps something like access(set, scope) would be
> better than scope(set). As it is, we’re conflating scop
> On Mar 3, 2017, at 4:05 AM, Rien wrote:
>
> Just scanned it, but my first impression is: LOVE IT!
>
> IMO this is the way to go.
>
> Though some of the details will no doubt be improved. I will read it in more
> depth coming WE.
Awesome, thanks! I have already received a lot of great feed
> On Mar 3, 2017, at 5:23 AM, Daniel Leping wrote:
>
> General impression is positive in case shortcuts (private, bulblic) still
> remain for the most common use cases.
The shorthand isn’t going anywhere. It is essential to making the system
practical and familiar.
>
> On Thu, 2 Mar 2017 a
I agree that “scope(set: file)” reads better. It does make it a little strange
that “scope(set)" is also valid, though; it’s ambiguous whether it takes
labeled or unlabeled arguments. Under this proposal, all of these are valid:
scope var == scope(get, lexical)
scope(set) v
I actually found the source, and it’s even an official one. :)
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID483
NOTE
In a class declaration, the static keyword has the same effect as
If I understand the model correctly, then classes structs and enums will have
an addition capability for their members.
static = access(type) access(override, nowhere)
class = access(type) access(override, everywhere)
You could combine type into one parameterized access, and make the capability
Can you check this translation, and maybe based on it’s (possible) mistakes
provide better examples in the next proposal draft on how one should think with
the new pure access model.
open class A {
open internal(set) var abc: Int = 42
public static func foo() {}
open class fu
> On Mar 3, 2017, at 1:12 PM, Adrian Zubarev
> wrote:
>
> If I understand the model correctly, then classes structs and enums will have
> an addition capability for their members.
>
> static = access(type) access(override, nowhere)
>
> class = access(type) access(override, everywhere)
>
> Y
> On Mar 3, 2017, at 11:26 AM, BJ Homer wrote:
>
> I agree that “scope(set: file)” reads better. It does make it a little
> strange that “scope(set)" is also valid, though; it’s ambiguous whether it
> takes labeled or unlabeled arguments. Under this proposal, all of these are
> valid:
>
> sc
> On Mar 3, 2017, at 1:26 PM, Adrian Zubarev
> wrote:
>
> Can you check this translation, and maybe based on it’s (possible) mistakes
> provide better examples in the next proposal draft on how one should think
> with the new pure access model.
>
> open class A {
>
> open internal(
> On Mar 3, 2017, at 1:36 PM, Adrian Zubarev via swift-evolution
> wrote:
> I actually found the source, and it’s even an official one. :)
>
> https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH
That makes totally sense to me, but thank you John for further clarification.
--
Adrian Zubarev
Sent with Airmail
Am 3. März 2017 um 21:30:11, John McCall (rjmcc...@apple.com) schrieb:
On Mar 3, 2017, at 1:36 PM, Adrian Zubarev via swift-evolution
wrote:
I actually found the source, and it’
> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution
> wrote:
>
> I have updated this proposal with a few more refinements based on yesterday’s
> discussion. You can find the final proposal on Github:
>
> https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilitie
Sent from my iPad
> On Mar 4, 2017, at 10:09 AM, Rien wrote:
>
>
>> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution
>> wrote:
>>
>> I have updated this proposal with a few more refinements based on
>> yesterday’s discussion. You can find the final proposal on Github:
>>
>>
IIRC we might want to introduce enum subtypes in the future right? In previous
discussions an enum, that can be subtyped outside your own module was written
as open enum. I also remember that Brent said enum sub typing should remove
cases from your parent enum. So what exactly might happen with
For all thous who expresses thoughts like "the proposal is too much of a
complexity": first of all - I like the open approach of it. It's easily
extensible. After that - it gives one the flexibility. For the newbies
there are shortcut aliases if they don't want (can't) dig deeper at the
moment.
I
Sent from my iPad
> On Mar 5, 2017, at 3:59 AM, Adrian Zubarev
> wrote:
>
> IIRC we might want to introduce enum subtypes in the future right? In
> previous discussions an enum, that can be subtyped outside your own module
> was written as open enum. I also remember that Brent said enum sub
Pardon me for jumping in without a whole load of quoting of previous messages
but :
1. My mailbox is getting crammed with messages that are over 90% quote,
sometimes running to hundreds of lines
2. I can't find a convenient message to attach this reply to
Matthew, please don't take any of the
22 matches
Mail list logo
