Re: [swift-evolution] final + lazy + fileprivate modifiers

I think it would be a step back as it again oversimplifies access control IMHO. If we touch access control we should aim to improve it from both a library implementation point of view but for a user point of view as well. Sent from my iPhone > On 16 Feb 2017, at 06:20, Chris Lattner via

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 16 Feb 2017, at 03:45, David Smith wrote: > >> >> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution >> wrote: >> >>> >>> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >>> On Feb 15, 2017, at

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 16, 2017, at 7:18 AM, Kevin Nattinger via swift-evolution > wrote: > > >> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution >> > wrote: >> >>> >>> On Feb 15, 2017, at 2:25 PM,

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

On Feb 15, 2017, at 6:02 AM, Sadiq via swift-evolution wrote: > I would like to suggest to change Logical NOT Operator from ! to something > else. > It will increase the readability of the code and will avoid any confusion > with the symbol used for force unwrapping

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Feb 14, 2017, at 11:46 PM, Jean-Daniel via swift-evolution wrote: >>> Keeping with the spirit of Swift and staying consistent with its design, I >>> see two plausible meanings for private: >>> >>> Private could mean either: ... >>> (2) accessible only to the

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution > wrote: > >> >> On Feb 15, 2017, at 2:25 PM, Charles Srstka > > wrote: >> >>> On Feb 15, 2017, at 3:11 PM, Itai Ferber

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution > wrote: > >> >> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >> >>> >>> On Feb 15, 2017, at 9:59 AM, Rien wrote: >>> On 15 Feb 2017, at 16:45,

Re: [swift-evolution] [Pitch] consistent public access modifiers - protocols

> On Feb 10, 2017, at 12:23, Matthew Johnson wrote: > > >> On Feb 10, 2017, at 12:52 PM, Jordan Rose > > wrote: >> >> Hi, Matthew. Thank you for bringing up these issues. I'm going to break my >> feedback up into

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution >> wrote: >> >> Having loosely followed this discussion, the way I'm thinking of ‘closed’

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution > wrote: > > Having loosely followed this discussion, the way I'm thinking of ‘closed’ is > as a modifier which would let you switch over something from outside the > module in which it is declared. >

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 18:16, Xiaodi Wu via swift-evolution > wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 21:52, Slava Pestov via swift-evolution > wrote: > > Also, note that there will be at least one other similar annotation, but for > structs — the evolution document calls it @fixedContents. We want a way to > declare that the set of stored

Re: [swift-evolution] [Pitch] consistent public access modifiers

> The Library Evolution document isn’t gospel; it’s more like a collection of > musings and aspirations, so I don’t think we should be bound by the syntax it > uses. Agreed on this very local point. :-) There are some deliberately ugly names in there so that we don't end up using that syntax.

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 15, 2017, at 2:25 PM, Charles Srstka wrote: > >> On Feb 15, 2017, at 3:11 PM, Itai Ferber > > wrote: >> >> FYI, Tony is the manager of the Foundation team. :) >> We care very much about making sure that the

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

> On 15 Feb 2017, at 22:44, Nicolas Fezans via swift-evolution > wrote: > > > 3: maybe ~ is a better fit? > > just for information this is in line with Matlab in which the following three > "not"-related syntax exist: > a) ~ as a prefix operator for not > b) not as

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

> 3: maybe ~ is a better fit? just for information this is in line with Matlab in which the following three "not"-related syntax exist: a) ~ as a prefix operator for not b) not as a function c) ~= as an infix operator for "is not equal to" I see pros and cons for each option and have a very

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 15, 2017, at 3:11 PM, Itai Ferber wrote: > > FYI, Tony is the manager of the Foundation team. :) > We care very much about making sure that the experience of using our > framework is a positive one — the more Radars we get, the better we can > prioritize improving

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 4:16 PM, David Hart wrote: > > >> On 15 Feb 2017, at 23:15, Matthew Johnson > > wrote: >> >>> >>> On Feb 15, 2017, at 4:12 PM, David Hart >> >

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 15 Feb 2017, at 23:15, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 4:12 PM, David Hart > > wrote: >> >>> >>> On 15 Feb 2017, at 16:31, Matthew Johnson >>

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 4:12 PM, David Hart wrote: > >> >> On 15 Feb 2017, at 16:31, Matthew Johnson > > wrote: >> >> >>> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 15 Feb 2017, at 16:31, Matthew Johnson wrote: > > >> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution >> > wrote: >> >> >>> On Feb 14, 2017, at 3:20 AM, David Hart

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

As of today, this is possible: prefix operator ¬ prefix func ¬ (value: Bool) -> Bool { return !value } let t = true let f = ¬t I have to admit that I quite like this but it has a couple drawbacks: 1: if you've never seen the ¬ operator in math it makes no more sense than "!" 2: It's quite

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> This definition of `scoped` is actually much different than the current > `private` which restricts visibility to the *current* scope. Your definition > allows visibility in an unlimited number of scopes that just happen to be of > the same type. I don’t think `scoped` is a good name for

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> > Here's an idea in three points: > > 1. Return to the Swift 2 definition of `private`. > 2. Introduce `scoped` to limit the visibility to within the same type, > subtype, or extension. > 3. Allow mixing the two. > > So you have: > > private // current file > private

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Was surprised that you expressed exactly what I'm thinking about this subject. > > I do believe even in Swift we need a way to say "only code that *knows* what > it does should see this" and to not force us to write(and manage) the the > code in same file. > Yes, some implementation details

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

There is no need to change it Since the context basically disambiguates the meaning of ! The next best thing is to compare it to false (val == false) // same as !val On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution < swift-evolution@swift.org> wrote: > If someone came with a

Re: [swift-evolution] Pitch: Replacement for FileHandle

FYI, Tony is the manager of the Foundation team. :) We care very much about making sure that the experience of using our framework is a positive one — the more Radars we get, the better we can prioritize improving APIs that are not working as well as they could be for our users. Even if the

Re: [swift-evolution] [Pitch] consistent public access modifiers

Types have a ton of different implicit/explicit “API”, and access control modifiers often implicitly define that API: - API for everyone to use when dealing with your concrete type (“public”) - API for module code when you have related, coupled types that need a higher degree of knowledge

Re: [swift-evolution] Does protocol support add to an object's size?

Values of concrete type always have the same size regardless of what protocols the type conforms to. Slava > On Feb 15, 2017, at 9:51 AM, Daryle Walker via swift-evolution > wrote: > > I don't know how protocol support works. I asking because I want to maintain >

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Le 15 févr. 2017 à 16:37, Michel Fortin via swift-evolution > a écrit : > >> >> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution >> a écrit : >> >> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: The beauty

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

If someone came with a nice syntax I’d be for this. I can’t imagine what that would be. I doubt there is an alternate prefix or postfix operator that would pass muster, due to ‘!’ already meaning the appropriate thing in so many languages, and swift only supporting symbolic operators. I can’t

Re: [swift-evolution] [Pitch] consistent public access modifiers

Not a huge response, but how about locked? --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 20:31:30, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb: > On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon > wrote: > >> On Feb 13,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon > wrote: > >> On Feb 13, 2017, at 7:45 AM, Matthew Johnson wrote: >> >> If you look closely, when most people say “closed enum” they mean a fixed, >> complete set of cases that are all public.

Re: [swift-evolution] [Pitch] consistent public access modifiers

> > On 15 Feb 2017, at 19:27, Adrian Zubarev > wrote: > > Inline: > > -- > Adrian Zubarev > Sent with Airmail > > Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb: > >> >> > On 15 Feb 2017, at 18:09, Adrian Zubarev

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 15, 2017, at 10:52 AM, Tony Parker wrote: > > Hi Charles, > > Have you happened to file a radar for Foundation that I can look up (for both > this and process)? > > We are working hard on making sure that our API is right for Swift, and areas > like this

Re: [swift-evolution] [Pitch] consistent public access modifiers

If you happen not to bump into these issues yet, then simply call yourself lucky. ;) --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 19:27:06, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: Inline: --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 19:11:12,

Re: [swift-evolution] [Pitch] consistent public access modifiers

Inline: --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb: > On 15 Feb 2017, at 18:09, Adrian Zubarev > wrote:  >  > As I already said:  >  > • To make that feature happen, we need the protocol to be

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

If that's the case, force unwrapping can be done with a different symbol. Personally I like '!' for force unwrapping. On Wed, Feb 15, 2017 at 11:45 PM, Jose Cheyo Jimenez wrote: > https://lists.swift.org/pipermail/swift-evolution/ > 2015-December/32.html > > Swift tries

Re: [swift-evolution] [Pitch] consistent public access modifiers

I’ll try again to make it a little bit more simpler. Assume we want to implement my feature to support document["string_literal", stringInstance, integerInstance, 42] where the first parameter type is always a String but the types follow afterward are either a String or an Int (literals should

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 18:09, Adrian Zubarev > wrote: > > As I already said: > > • To make that feature happen, we need the protocol to be public > (regardless if you can conform to it or not). > • Today you can conform to every protocol because in

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

So you've identified the problem, but what do you propose as a solution here? It should be noted that a (non-stdlib) language-level answer to this question has already been discussed and rejected (https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html). ~Robert Widmann

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:45, Matthew Johnson wrote: > > >> On Feb 15, 2017, at 10:35 AM, Rien wrote: >> >>> >>> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >>> On Feb 15, 2017, at 9:59 AM, Rien

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution >> wrote: >> >> Keeping with the spirit of Swift and staying consistent with its design, I

Re: [swift-evolution] Simplifying Access Using 'Hidden'

Inline On 15.02.2017 18:37, Michel Fortin wrote: Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution a écrit : On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: The beauty of Swift 2's access modifiers was that they were based around files and

[swift-evolution] [Accepted] SE-0152: Package Manager Tools Version

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md The review of SE-0152 "Package Manager Tools Version" ran from February 7 until February 14. There wasn't much discussion on the mailing list, but we did receive some off-list

[swift-evolution] [Accepted] SE-0151: Package Manager Swift Language Compatibility Version

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md The review of SE-0151 "Package Manager Swift Language Compatibility Version" ran from February 7 until February 14. There wasn't much discussion on the

[swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

Hello, I would like to suggest to change Logical NOT Operator from ! to something else. It will increase the readability of the code and will avoid any confusion with the symbol used for force unwrapping of optional values. It would be easier for new programmers to learn Swift as the first

Re: [swift-evolution] [Pitch] consistent public access modifiers

To summarize everything, I think whenever we get submodules in Swift having a consistent public vs. open behavior would have a great impact when some of us will work on huge (team) projects. I do not actively support the idea of @closed. I see its benefits, but first I need to get my head

Re: [swift-evolution] [Pitch] consistent public access modifiers

As I already said: To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not). Today you can conform to every protocol because in reality they are open today. If we remove the property requirement from the protocol the client can conform it to

Re: [swift-evolution] Pitch: Replacement for FileHandle

Hi Charles, Have you happened to file a radar for Foundation that I can look up (for both this and process)? We are working hard on making sure that our API is right for Swift, and areas like this where we can make fairly trivial improvements are things that we can try to prioritize. As you

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution > wrote: > > A short example where I personally wanted a public-but-not-open protocol: > > public protocol SubscriptParameterType { > > // This property was needed to prevent the client from

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 10:35 AM, Rien wrote: > >> >> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >> >>> >>> On Feb 15, 2017, at 9:59 AM, Rien wrote: >>> On 15 Feb 2017, at 16:45, Matthew Johnson

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Le 15 févr. 2017 à 10:52, Matthew Johnson a écrit : > > >> On Feb 15, 2017, at 9:37 AM, Michel Fortin via swift-evolution >> wrote: >> >> >>> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution >>> a

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 9:59 AM, Rien wrote: >> >>> >>> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: >>> On Feb 15, 2017, at 9:35 AM, Rien

Re: [swift-evolution] [Pitch] consistent public access modifiers

A short example where I personally wanted a public-but-not-open protocol: public protocol SubscriptParameterType { // This property was needed to prevent the client from breaking // the library by conforming to the protocol, but I'd like to // keep it invisible for the client,

Re: [swift-evolution] Rules for structs default/memberwise initializers

Thanks Matthew. That’s a quite elaborated proposal! I’ll be sure to keep an eye on it as we move forward. Dimitri On 15 Feb 2017, at 16:57, Matthew Johnson > wrote: Hi Dimitri, You may be interested in taking a look at a proposal I

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 9:59 AM, Rien wrote: > >> >> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: >> >>> >>> On Feb 15, 2017, at 9:35 AM, Rien wrote: >>> >>> On 15 Feb 2017, at 16:11, Matthew Johnson via

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 9:35 AM, Rien wrote: >> >> >>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >>> wrote: >>> >>> On Feb 15, 2017,

Re: [swift-evolution] Rules for structs default/memberwise initializers

Hi Dimitri, You may be interested in taking a look at a proposal I introduced about a year ago which was deferred. Memberwise initialization is a topic we intend to revisit eventually. This may happen in phase 2 of the Swift 4 effort, or may not happen until Swift 5.

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> On Feb 15, 2017, at 9:37 AM, Michel Fortin via swift-evolution > wrote: > > >> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution >> a écrit : >> >> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: The beauty of

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 9:35 AM, Rien wrote: > > >> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >> wrote: >> >> >>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution >>> wrote: >>>

Re: [swift-evolution] final + lazy + fileprivate modifiers

"Either keep it or drop it, but don't keep fiddling with it." sums up my position well. On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution > a écrit : > > On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: >>> The beauty of Swift 2's access modifiers was that they were based >>> around files and modules, explicitly rejecting types and

[swift-evolution] Rules for structs default/memberwise initializers

Hello community! While writing a Swift introduction tutorial for students, I’ve been stumbling upon the rules for struct default and memberwise initializers. I failed to find explanations in Apple’s language guide, but as far as I could observe, I think the rules don’t fit interesting

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution > wrote: > > >> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution >> wrote: >> >> >>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution > wrote: > > >> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote: >> >> >> On 14 Feb 2017, at 09:25, Goffredo Marocchi >

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution > wrote: > > >> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >> wrote: >> >> >> Our philosophy in general, however, is to default to the behavior

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:52 AM, Jeremy Pereira > wrote: > > >> On 15 Feb 2017, at 02:16, Xiaodi Wu via swift-evolution >> wrote: >> >> So, perhaps I'm being simplistic here, but-- >> >> At the end of the day, aren't we simply

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:11 AM, Brent Royal-Gordon > wrote: > >> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu wrote: >> >> So, perhaps I'm being simplistic here, but-- >> >> At the end of the day, aren't we simply trying to enable a resiliency >>

Re: [swift-evolution] [Discussion] Variadics as an Attribute

>> There is a lot of design overlap. That is the reason why I think we should >> vision variadics as a whole in its future rather than simply repaint … >> postfix to a type annotation keyword @variadics. This will only close the >> doors for some features we might want to add in a future

Re: [swift-evolution] Simplifying Access Using 'Hidden'

On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: The beauty of Swift 2's access modifiers was that they were based around files and modules, explicitly rejecting types and scopes as units for determining visibility. It seems at base there's a group of people who reject that decision

Re: [swift-evolution] [Discussion] Variadics as an Attribute

+1 I don't see tuples as a better solution for this without substantial work. Even after all of that work, I am not convinced that tuples would be a better solution. On Wed, Feb 15, 2017 at 7:16 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > –1 for me, I’ll explain

Re: [swift-evolution] [Discussion] Variadics as an Attribute

> On 15 Feb 2017, at 12:16, Adrian Zubarev > wrote: > > I gave the topic a down vote not because I don’t like the proposal, but > because I personally see variadics go into the direction of tuples. > Especially I’d love to see some more talk about tuples in

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

That’s the other side of the coin, but it does not prevent you from putting anything you’d like to as your profile picture. The point I’m trying to make is that I don’t think anyone wants to moderate such content, but that’s only a personal preference of mine. ;) --  Adrian Zubarev Sent with

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

> On Feb 9, 2017, at 6:17 AM, Adrian Zubarev via swift-evolution > wrote: > > Personally I’d prefer (if possible) that we’d remove profile pictures from > the forum and simply have only full names (colored?) + some kind of > annotation (e.g. Core Team, etc.).

Re: [swift-evolution] [Discussion] Variadics as an Attribute

–1 for me, I’ll explain in a moment. To help you find the old topic you can use the proof-of-concept Discourse setup from Nate Cook: http://discourse.natecook.com/t/proposal-variadics-as-attribute/2075/20 The link above also reflects Chris Lattners opinion on this topic. I gave the topic a

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution > wrote: > > Keeping with the spirit of Swift and staying consistent with its design, I > see two plausible meanings for private: > > Private could mean either: > 1) private to the file (Swift 2

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution > wrote: > > > Our philosophy in general, however, is to default to the behavior which > preserves the most flexibility for the library designer. Actually, I thought the philosophy was to preserver

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 02:16, Xiaodi Wu via swift-evolution > wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases

Re: [swift-evolution] [Discussion] Variadics as an Attribute

Immediate followup, but is there something wrong with the gmane site that we've been using to provide links to mailing list discussions? I can't seem to get a list of recent topics so I can find out what the new discussion link should be. > On 15 Feb 2017, at 11:38, Haravikk via swift-evolution

[swift-evolution] [Discussion] Variadics as an Attribute

I'm posting this as a new discussion topic for my earlier proposal of Variadics as an Attribute. I would have reused the old topic but I have no idea how to do that on a mailing list once the messages are gone (I don't keep them for long); I'm looking forward to the possible switch to

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution > wrote: > > I do like approach #2. It would play well with extensions, look very familiar > to how private works in other main stream languages and it wouldn’t get in > the way of a possible

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> The beauty of Swift 2's access modifiers was that they were based around > files and modules, explicitly rejecting types and scopes as units for > determining visibility. It seems at base there's a group of people who reject > that decision altogether. Hence, new `private`, proposals around

Re: [swift-evolution] final + lazy + fileprivate modifiers

> 1) private to the file (Swift 2 semantics) > 2) accessible only to the current type/scope and to extensions to that type > that are in the current file. Imho the old model had the benefit that it made things like C++ "friend" superfluous, so I prefer 1) over 2). It is simpler, and from a

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases aren't > source-breaking is a

Re: [swift-evolution] array splatting for variadic parameters

> I didn't get an especially positive response to the proposal at the time, but > it is still very much my preferred solution. I'm convinced that the timing had a very huge impact on the reaction: It was a very busy period, and I had a strong impression that people just wanted to limit the

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

+1 On 15 February 2017 at 15:12, Dietmar Planitzer via swift-evolution < swift-evolution@swift.org> wrote: > I would love to see this - and the sooner the better :) > > I think that the fact that Swift makes a type-level distinction between > optional and non-optional makes it easier to trip

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

I would love to see this - and the sooner the better :) I think that the fact that Swift makes a type-level distinction between optional and non-optional makes it easier to trip yourself up when you work with Cocoa APIs that use pseudo-optionality, compared to when you work with ObjC. In ObjC

Re: [swift-evolution] final + lazy + fileprivate modifiers

I do like approach #2. It would play well with extensions, look very familiar to how private works in other main stream languages and it wouldn’t get in the way of a possible future refinement of extensions to this model: a) 1st party extension (extension defined and owned by the type owner):

Re: [swift-evolution] array splatting for variadic parameters

> "Splatting" as the OP suggests is a simpler solution, but leaves variadics > limited to a unique syntax with no control over type; I also your prefer the proposal than my initial suggestion. > I could of course be biased, but then I've never really supported variadics > as a feature in the

Re: [swift-evolution] array splatting for variadic parameters

> On 14 Feb 2017, at 20:43, Anton Zhilin via swift-evolution > wrote: > > 2017-02-14 18:32 GMT+03:00 Dimitri Racordon via swift-evolution > >: > > > > The proposal is indeed really interesting. > I

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution > wrote: > > >> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote: >> >> >> On 14 Feb 2017, at 09:25, Goffredo Marocchi >