Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

I totally agree. For clarity, are we in agreement that the definition of "folder" is the underlying file system's implementation of a folder rather than some metadata setting? I am thinking of how Xcode as a view of project folder that at times can leave on one confused. My preference is to

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Ok, thanks - Jim From: Adrian Zubarev Sent: Thursday, December 8, 2016 7:38:22 AM To: Jim Malak Cc: swift-evolution@swift.org Subject: Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

I realise the general opinion here seems to be that we don't want any more changes to the access modifiers and I can understand why, but please take a look at the use case below: "fileprivate" is needed for certain things like Equatable since the equatable function might need to know about

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Since Xcode is not a requirement for Swift development no, I was talking about a file system folder. > On 8 Dec 2016, at 13.30, Jim Malak via swift-evolution > wrote: > > I totally agree. For clarity, are we in agreement that the definition of > "folder" is the

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

As an advice, you should first hear out what the community thinks about the idea, before writing anything, because one person might share your idea. Others including myself may not like it. Wait for more feedback first. ;) --  Adrian Zubarev Sent with Airmail Am 8. Dezember 2016 um 13:35:56,

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

-1 from me. On Thu, Dec 8, 2016 at 7:39 AM, Jim Malak via swift-evolution < swift-evolution@swift.org> wrote: > Ok, thanks > > - Jim > -- > *From:* Adrian Zubarev > *Sent:* Thursday, December 8, 2016 7:38:22 AM > *To:* Jim Malak >

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Did someone ask for more feedback? Overall, I'm pretty -1 on this proposal. I never really liked the fileprivate solution of scope being created to match (in my mind not quite related) file system/organizational boundaries of files–but it was the best compromise we could come up with at the

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

I understand. I am not fixed on this approach ether. I do believe that there needs to be a controllable layer of granularity with respect to what is exposed inside of an extension. I was used this approach since the fileprivate was already there. I am not looking to make a perceived bad

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Will discprivate be next? and then systemprivate? -1 Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution >

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

My standard reply is that when a type implementation gets this big, it is quite possible that the design is sub optimal. An equate operation between types almost always means that they have something in common that can be isolated into its own file which then also includes the equate

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

It is hard to argue with that :) I think the problem with more or less all new access level modifiers is that while there are legit uses for folderprivate, typeprivate and what else have been proposed recently, all of them also allow for some pretty no-legit anti-pattern uses as well. I will

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Great. Is there some other steps I should go through or is the next step to write a draft proposal? Kind regards, Jim Malak Director Beryle & Lee, Inc, O +1-330-818-2600 M +1-234-716-2658 F +1-330-818-2560 email/Skype: jim.ma...@beryle-lee.com

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Overkill or not, grouping files into a folder/group + folderprivate smells exactly like a submodule to me. ;) The only thing I’m repeating over and over is that we should fix that open mess and allow protocols to have the same open/public access level as classes have. open protocol from module

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

I think this is a great idea! I would prefer calling it folderprivate tho. > On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution > wrote: > > Whoops I meant directoryprivate not dictionaryprivate. I’m probably still > sleepy. > > > > > -- > Adrian

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Personal statement: –1 --  Adrian Zubarev Sent with Airmail Am 8. Dezember 2016 um 12:26:17, Aron Lindberg (ar...@me.com) schrieb: I think this is a great idea! I would prefer calling it folderprivate tho. On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

I guess it's just coincidence, but this thread about "directoryprivate" did start while the thread about "typeprivate" (which ended up as a general discussion) is fading away without real results… To me, this looks like an indication for two* things: a) Access levels are broken** in Swift 3

[swift-evolution] CMTimebaseAddTimerDispatchSource and new libdispatch swift 3 version

Hi, I’m migrating some code from swift 2 to swift 3, and I use the CoreMedia timebase API (CMSync). One of the functions I use is CMTimebaseAddTimerDispatchSource whose documentation (https://developer.apple.com/reference/coremedia/1489429-cmtimebaseaddtimerdispatchsource

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

-1 we don't need any more access modifiers. We already have an excessive amount: 5 On Thu, Dec 8, 2016 at 12:55 PM Jim Malak via swift-evolution < swift-evolution@swift.org> wrote: > Hi Tino, > This is my first use of this forum. I certainly did not mean to cause pain > for anyone. > At Gonzalo's

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

@Jim You most certainly offended no one! Quite the opposite. This being an open source community, every contribution counts and, imho, you did nothing but to *contribute *to swift's evolution! Thanks for backing typeprivate proposal. We have been looking for ways to restructure our proposal

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

> On 8 Dec 2016, at 12:52, Aron Lindberg via swift-evolution > wrote: > > I realise the general opinion here seems to be that we don't want any more > changes to the access modifiers and I can understand why, but please take a > look at the use case below: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

> On Dec 7, 2016, at 10:07 PM, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0147 "Move UnsafeMutablePointer.initialize(from:) to > UnsafeMutableBufferPointer" begins now and runs through December 12, 2016. > The proposal is available here: > >

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Hi Jim, > This is my first use of this forum. I certainly did not mean to cause pain > for anyone. I hope I didn't sound as if I was blaming you — imho it is not realistic to keep track of the evolution process as it is organised now, so even exact repetition is rather common > At Gonzalo's

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Hi Tino, This is my first use of this forum. I certainly did not mean to cause pain for anyone. At Gonzalo's invitation I have looked over the thread for his proposal and I am withdrawing my request and backing his with a very heavy +1. The group has done an amazing job with the open source

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

> On Dec 8, 2016, at 10:24 AM, Alex Martini via swift-evolution > wrote: > > >> On Dec 7, 2016, at 10:07 PM, Douglas Gregor > > wrote: >> >> Hello Swift community, >> >> The review of SE-0147 "Move

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

on Thu Dec 08 2016, Ben Cohen wrote: >> On Dec 2, 2016, at 8:27 PM, Nate Cook wrote: >> >>> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution >>> > >>> wrote: > >>> On Dec 1, 2016, at 11:33 PM, Nate

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

> On Dec 2, 2016, at 8:27 PM, Nate Cook wrote: > >> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution >> > wrote: >> >>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution >>>

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

> On Dec 8, 2016, at 3:50 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Dec 08 2016, Ben Cohen wrote: > >>> On Dec 2, 2016, at 8:27 PM, Nate Cook wrote: >>> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution

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

on Thu Dec 08 2016, Alexis Beingessner wrote: >> On Dec 8, 2016, at 3:50 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Thu Dec 08 2016, Ben Cohen wrote: >> > On Dec 2, 2016, at 8:27 PM, Nate Cook

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

> On Dec 8, 2016, at 16:22, Andrew Trick via swift-evolution > wrote: > > In practice, it needs to be able to interoperate with [UInt8] and be > interchangeable in the same generic context. > > e.g. `byteBuffer += rawBuffer[payloadIndex..

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

> On Dec 8, 2016, at 16:53, Ben Cohen wrote: > > >> On Dec 8, 2016, at 4:35 PM, Jordan Rose via swift-evolution >> > wrote: >> >> Um, Sequence doesn’t have a subscript (or indexes). Sequences are >>

[swift-evolution] Generic types—covariance/contravariance

Has the core team or the community considered the possibility of implementing covariant/contravariant generic types? It would really be appreciated. I know with Array, vague-ifying or specific-ifying the type ([Int] to [Any]) has help from the compiler—and we can use `map` if all else

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

> On Dec 8, 2016, at 4:35 PM, Jordan Rose via swift-evolution > wrote: > > Um, Sequence doesn’t have a subscript (or indexes). Sequences are > single-pass. So if this is important, it needs to stay a Collection. > Just because something fulfills one of the

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

> On Dec 8, 2016, at 12:50 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Dec 08 2016, Ben Cohen wrote: > >>> On Dec 2, 2016, at 8:27 PM, Nate Cook wrote: >>> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution

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

on Thu Dec 08 2016, Xiaodi Wu wrote: Can you elaborate on this? Why aren't you sure this is a wise idea? Whom are you asking? What is “this?” -- -Dave ___ swift-evolution mailing list swift-evolution@swift.org

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

> On Dec 8, 2016, at 4:54 PM, Jordan Rose wrote: > > >> On Dec 8, 2016, at 16:53, Ben Cohen > > wrote: >> >> >>> On Dec 8, 2016, at 4:35 PM, Jordan Rose via swift-evolution >>>

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

Sorry, let me clarify. Can you, Dave, elaborate as to why the issue you stated as "this" ("untyped memory without bounds checks" conforming to Collection) seems, as you say, "suspect"? On Thu, Dec 8, 2016 at 18:32 Dave Abrahams wrote: on Thu Dec 08 2016, Xiaodi Wu wrote:

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

On Thu, Dec 8, 2016 at 6:53 PM, Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 8, 2016, at 4:35 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > > Um, Sequence doesn’t have a subscript (or indexes). Sequences are > single-pass. So if this

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

> On Dec 8, 2016, at 5:44 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Dec 8, 2016 at 6:53 PM, Ben Cohen via swift-evolution > > wrote: > >> On Dec 8, 2016, at 4:35 PM, Jordan Rose via

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

So now that I look at it, it appears UnsafeRawBufferPointer(copyBytes:) has the same problems we are trying to solve on initialize(as:from) i.e. it is completely at the mercy of the passed-in collection's count being accurate, and if it isn't it'll scribble over memory. We should probably apply

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

Probably needs an argument label since it's performing an explicit purpose, not just a vanilla conversion initializer. So maybe UnsafeRawBufferPointer.init(rebasing:) Or since we have same-type constrained extensions now on master maybe you could do it as a property: extension

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

Can you elaborate on this? Why aren't you sure this is a wise idea? On Thu, Dec 8, 2016 at 16:19 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Dec 08 2016, Alexis Beingessner wrote: > > >> On Dec 8, 2016, at 3:50 PM, Dave Abrahams