Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Nov 30, 2016, at 6:15 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed Nov 30 2016, Kevin Ballard > wrote: > >> This sounds like a sensible idea. But there is one behavioral change you >> haven't addressed, which is that this changes how indexes

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

*I might even be willing to inhibit deduction,by default, of all generic function type parameters that don't appear inthe parameter list.* ^ If this was adopted, what Dave is proposing is: func f() -> T // error: generic parameter T must be explicit func f() -> T // ok On Thu, 1

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

I like this proposal! +1 Oldvalue and newvalue have different meanings. I have witnesses programmers overriding oldvalue with the name newvalue and vice versa. Of course if you are good at reading the documentation then you would not make the mistake. Swift should be a language that prevents a

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

*Unlike C++'s templates, a Swift's generic function is semantically a single function.* Anton, could you provide further insight on this? On Fri, 2 Dec 2016 at 01:03 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > I disagree with the suggestion. Unlike C++'s templates, a

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

*Yeah, this makes sense. Presumably this means that one could also write* * foo<>(1)* *where everything is still deduced. In C++, this syntax exists and means that non-template functions named “foo” are ignored.* Yes, it means so. One could have: foo() foo<>() // redundant foo<_>()

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

on Wed Nov 30 2016, Douglas Gregor wrote: >> On Nov 30, 2016, at 4:09 PM, Dave Abrahams via swift-evolution > wrote: >> >> >> on Mon Nov 28 2016, Douglas Gregor >> >> > >> wrote: >> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution >>

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Brandon *Is anyone starting to think the current access control model will become more burdensome over time?* *People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern lan

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0145: Package Manager Version Pinning (Revised)

Haven’t had a chance to catch up on the latest discussion, but I just saw that the Yarn developers posted an excellent piece on lockfiles this week: https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all They argue lockfiles should be commi

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

It seems odd that no review or comment has been made as the PR seems a step in the right direction. Sent from my iPhone > On 1 Dec 2016, at 14:17, Adrian Zubarev via swift-evolution > wrote: > > You forgot to mention Brent. ;) > > -- > Adrian Zubarev > Sent with Airmail > > Am 1. Dezember

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> This keeps leading me back to having submodules or creating modules on > demand. I think that would open up this system to great complexity. I meant "flexibility"...not complexity. Freudian slip? 😂 Brandon ___ swift-evolution mailing list swift-ev

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Is anyone starting to think the current access control model will become more burdensome over time? People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language. F

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

I'm also against this (though I like the first alternative about warning on set(oldValue) etc.). While I think there may be value in either preventing name overrides or requiring them here, I don't believe it's worth a breaking change. Then again, I have never personally encountered the problem (I

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

on Thu Dec 01 2016, Jordan Rose wrote: >> On Nov 30, 2016, at 16:15, Dave Abrahams via swift-evolution > wrote: >> >> >> on Wed Nov 30 2016, Kevin Ballard >> >> > >> wrote: >> >>> This sounds like a sensible idea. But there is one behavioral change you >>>

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Nov 30, 2016, at 16:15, Dave Abrahams via swift-evolution > wrote: > > > on Wed Nov 30 2016, Kevin Ballard > wrote: > >> This sounds like a sensible idea. But there is one behavioral change you >> haven't addressed, which is that this changes how indexe

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Aron, I did take a look at that document while developing the proposal. As you stated, it's a little old, however the principles of access control and their purpose remain pretty much the same. ".keep private details of a class hidden from the rest of the app .keep interna details of a framework

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Hi, Am 2016-12-01 11:08, schrieb Álvaro Monteiro via swift-evolution: > - Typeprivate would allow to abandon the odd fileprivate. Access level > would be constrained to swift constructs (structs, classes and > extensions) and not to a compiler artifact (file). Files are not compiler artifacts but

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

We really need a place for discussions that apply to deferred issues. Some previous suggestions from myself and others have been: - A Discourse board - Tag emails [4.1] (or something else) if they are known to relate to deferred proposals. - A ‘deferred’ directory for complete proposal

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Tino: Regarding the following statement - "Even if there was a change of mind, fileprivate is still needed for essential things like implementing Equatable.” How exactly is that so? Am I missing something? > > - Typeprivate would allow to abandon the odd fileprivate. Access level > > would be c

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I know it is a little old, but this is a nice read about the motivation for Swift's original access modifiers and why 'Protected' was not defined as an access level. https://developer.apple.com/swift/blog/?id=11 I think the point here is that ac

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

This discussion has been had on this list several times already. Using a name other than fileprivate, in particular, was part of the original discussion and the core team selected the current spelling. As Tino mentioned, submodules are a topic that the community has already expressed some interest

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Daniel, agree. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 14:23, Daniel Leping wrote: > > Gonçalo, I can suggest a bit different API to avoid clashing. Something like: > > private (file, set) > > Instead of: > > private (file) (set) > > Looks easier

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Gonçalo, I can suggest a bit different API to avoid clashing. Something like: private (file, set) Instead of: private (file) (set) Looks easier to me as it poses a possibility just to list the attributes in a pretty much standard way. On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swi

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

You forgot to mention Brent. ;) --  Adrian Zubarev Sent with Airmail Am 1. Dezember 2016 um 15:03:07, Anton Zhilin (antonyzhi...@gmail.com) schrieb: I disagree with the suggestion. Unlike C++'s templates, a Swift's generic function is semantically a single function. One can say that together wi

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

*@Daniel* I am very fond of your idea, as I believe it add extra flexibility to this solution, as Álvaro mentioned. My only concern is somehow related to semantics. Should we add the extra scope detail as you suggest, then it could clash with the current way of setting a setter as private or filepr

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

I disagree with the suggestion. Unlike C++'s templates, a Swift's generic function is semantically a single function. One can say that together with a metatype parameter, we pass in witness table. What I think we should do is make metatypes easier to use. *Adrian and I have a PR* that has already

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Let's add "private (ancestors)" on top. As a framework developer I really miss it. On Thu, 1 Dec 2016 at 15:34 Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > > @Tino: Regarding the following statement - "Even if there was a change of > mind, fileprivate is still needed for es

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> @Tino: Regarding the following statement - "Even if there was a change of > mind, fileprivate is still needed for essential things like implementing > Equatable.” > How exactly is that so? Am I missing something? class Eq: Equatable { private var value = 0 } func ==(lhs: Eq, rhs: Eq)

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Tino: Regarding the following statement - "Even if there was a change of mind, fileprivate is still needed for essential things like implementing Equatable.” How exactly is that so? Am I missing something? > > - Typeprivate would allow to abandon the odd fileprivate. Access level > > would be c

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> private(scope) decl > > Where scope is optional and defaults to full private. Can take "file" and > "type" values. I.e: > > private (file) var i = 1 > private func a() > private (type) func b() > > This way we can have a very fine grained access levels and maintain a better > structure. Wh

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Daniel: Very good idea because and it makes access control much more flexible. @Tino: Couldn't agree with you more about the usage of "swifty". I think it's applicable here because communication is something that everyone agrees is a essential in swift and access control is one of the many ways

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Exactly. Totally agree Tino. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 09:31, Tino Heth <2...@gmx.de> wrote: > > >> It also means that anybody who want to access your private var will just >> have to write an extension to expose it. > imho this is wron

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> - Typeprivate would allow to abandon the odd fileprivate. Access level would > be constrained to swift constructs (structs, classes and extensions) and not > to a compiler artifact (file). Actually, imho fileprivate isn't odd or "unswift"* — it's one of the three original levels, which all rel

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

How about making things more organized and move to syntax like this: private(scope) decl Where scope is optional and defaults to full private. Can take "file" and "type" values. I.e: private (file) var i = 1 private func a() private (type) func b() This way we can have a very fine grained acces

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I think the idea behind this proposal is quite the contrary. It is about conveying the right message through the use of an expressive access control that addresses common use cases and leaves behind fileprivate which IMHO is a C inherited way of thinking. Let me try to be clear: - Private would w

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

-1 I'm more or less neutral towards the change itself, but combined with the breaking effect, that's a clear "no". None the less, I hope that the whole topic with all its magic words (willSet, didSet, newValue, oldValue…) will be reworked in the future, which would be another argument not to f

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> It also means that anybody who want to access your private var will just have > to write an extension to expose it. imho this is wrong thinking: Access control is no tool to offer real "protection" — it can't stop someone who wants to break a system. Especially in the world of open source, it

[swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

> This pitch is breaking, and should be considered under the phase 1 timeframe. > gist here:https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b I don’t agree with this proposal, -1 -g. PS: The first alternative might be useful though: “… Swift could still warn or error on set(old

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Still better than exposing to any subclass implementation or direct external access IMHO. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 07:40, Jean-Daniel wrote: > > If you add a typeprivate accessor, it means you expose your internal details > to all ex