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

[Ben Cohen via swift-evolution]

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 RandomAccessSlice where Base == UnsafeRawBufferPointer {
var rebased: UnsafeRawBufferPointer {
return UnsafeRawBufferPointer(start: base.baseAddress, count: count)
}
}

(written by hand without a compiler so unlikely to be correct :)

> On Dec 8, 2016, at 18:07, Andrew Trick  wrote:
> 
> 
>> 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 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 requirements of a Collection 
>>> does not mean it should be one. It needs to tick all the boxes before its 
>>> allowed to be elevated.
>>> 
>>> But it’s still allowed to have subscripts (UnsafePointer has subscripting 
>>> but isn’t a collection) or be multi-pass (strides are multiples but are 
>>> only sequences). That’s OK
>>> 
>>> In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t 
>>> a collection because it doesn’t meet the requirements for slicing i.e. that 
>>> indices of the slice be indices of the parent.
>>> (relatedly… it appears this requirement is documented on the concrete Slice 
>>> type rather than on Collection… which is a documentation bug we should fix).
>> 
>> If this is indeed a requirement for Collection, then my vote would be for 
>> Nate's option #1 and Andy's option #2, to give UnsafeRawBufferPointer a 
>> Slice type that fulfills the requirement. It's the smallest change, 
>> preserves the use of integer indices, and preserves what Andy stated as the 
>> desired use case of making it easy for users to switch out code written for 
>> [UInt8].
> 
> Ok, but there needs to be an easy way in a nongeneric context to convert from 
> a Slice into an URBP (with normalized byte offsets).
> 
> Does anyone object to adding an initializer for this? Any suggestions on 
> naming? Do we need an argument label? etc?
> 
> UnsafeRawBufferPointer(_ : Slice)
> 
> as in:
> 
> let region = UnsafeRawBufferPointer(buffer[i.. 
> -Andy
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

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 similar fixes 
and change it to take a sequence.

I realize it's a sticking plaster on this particular issue though, so still 
doesn't answer whether it's better for UnsafeRawBufferPointer to be a 
collection, just created more work...

> On Dec 8, 2016, at 17:06, Andrew Trick  wrote:
> 
> 
>>> 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 
  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 requirements of a Collection 
>>> does not mean it should be one. It needs to tick all the boxes before its 
>>> allowed to be elevated.
>>> 
>>> But it’s still allowed to have subscripts (UnsafePointer has subscripting 
>>> but isn’t a collection) or be multi-pass (strides are multiples but are 
>>> only sequences). That’s OK
>>> 
>>> In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t 
>>> a collection because it doesn’t meet the requirements for slicing i.e. that 
>>> indices of the slice be indices of the parent.
>>> (relatedly… it appears this requirement is documented on the concrete Slice 
>>> type rather than on Collection… which is a documentation bug we should fix).
>> 
>> Ah, right, thank you. Retracted.
> 
> Let me restate, because I think Jordan's question was valid given my 
> statement.
> 
> It would be *nice* for raw buffers to be Collection because they’re 
> meant to be a replacement for code that is typically written for [UInt8], and 
> anything you can do with an array that applies to raw buffers is covered by 
> Collection.
> 
> However, I don’t expect the raw buffer to be used in a generic context except 
> being passed to utilities that copy the bytes out. That will either be done 
> by directly iterating over the collection or invoking some other API that 
> could take a Sequence. The most important is probably 
> Array.append(contentsOf:), which is moving over to Sequence. However, we 
> would also need to change UnsafeRawBufferPointer(copyBytes:), 
> NSData(replaceSubrange:), and whatever else I haven't thought of. That's a 
> small disadvantage to this solution.
> 
> I'm also a little concerned that Sequence is immutable, so generic code has 
> no way to copy bytes into the buffer.
> 
> My bigger concern is still that the range subscript’s inconsistent behavior 
> may still lead to bugs in practice in nongeneric code.
> 
> -Andy
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrew Trick via swift-evolution]

> 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 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 requirements of a Collection does 
> not mean it should be one. It needs to tick all the boxes before its allowed 
> to be elevated.
> 
> But it’s still allowed to have subscripts (UnsafePointer has subscripting but 
> isn’t a collection) or be multi-pass (strides are multiples but are only 
> sequences). That’s OK
> 
> In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t a 
> collection because it doesn’t meet the requirements for slicing i.e. that 
> indices of the slice be indices of the parent.
> (relatedly… it appears this requirement is documented on the concrete Slice 
> type rather than on Collection… which is a documentation bug we should fix).
> 
> If this is indeed a requirement for Collection, then my vote would be for 
> Nate's option #1 and Andy's option #2, to give UnsafeRawBufferPointer a Slice 
> type that fulfills the requirement. It's the smallest change, preserves the 
> use of integer indices, and preserves what Andy stated as the desired use 
> case of making it easy for users to switch out code written for [UInt8].

Ok, but there needs to be an easy way in a nongeneric context to convert from a 
Slice into an URBP (with normalized byte offsets).

Does anyone object to adding an initializer for this? Any suggestions on 
naming? Do we need an argument label? etc?

UnsafeRawBufferPointer(_ : Slice)

as in:

let region = UnsafeRawBufferPointer(buffer[i..

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

[Xiaodi Wu via swift-evolution]

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 is important, it needs to stay a Collection.
>
>
> Just because something fulfills one of the requirements of a Collection
> does not mean it should be one. It needs to tick all the boxes before its
> allowed to be elevated.
>
> But it’s still allowed to have subscripts (UnsafePointer has subscripting
> but isn’t a collection) or be multi-pass (strides are multiples but are
> only sequences). That’s OK
>
> In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t
> a collection because it doesn’t meet the requirements for slicing i.e. that
> indices of the slice be indices of the parent.
> (relatedly… it appears this requirement is documented on the concrete
> Slice type rather than on Collection… which is a documentation bug we
> should fix).
>

If this is indeed a requirement for Collection, then my vote would be for
Nate's option #1 and Andy's option #2, to give UnsafeRawBufferPointer a
Slice type that fulfills the requirement. It's the smallest change,
preserves the use of integer indices, and preserves what Andy stated as the
desired use case of making it easy for users to switch out code written for
[UInt8].

I'm not sure I fully understand yet why Dave finds the idea of Collection
conformance fishy, but I'm comfortable with a type that's clearly labeled
as unsafe not being fully footgun-proof.


>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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:

> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrew Trick via swift-evolution]

> 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 
>>> > 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 requirements of a Collection does 
>> not mean it should be one. It needs to tick all the boxes before its allowed 
>> to be elevated.
>> 
>> But it’s still allowed to have subscripts (UnsafePointer has subscripting 
>> but isn’t a collection) or be multi-pass (strides are multiples but are only 
>> sequences). That’s OK
>> 
>> In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t a 
>> collection because it doesn’t meet the requirements for slicing i.e. that 
>> indices of the slice be indices of the parent.
>> (relatedly… it appears this requirement is documented on the concrete Slice 
>> type rather than on Collection… which is a documentation bug we should fix).
> 
> Ah, right, thank you. Retracted.

Let me restate, because I think Jordan's question was valid given my statement.

It would be *nice* for raw buffers to be Collection because they’re 
meant to be a replacement for code that is typically written for [UInt8], and 
anything you can do with an array that applies to raw buffers is covered by 
Collection.

However, I don’t expect the raw buffer to be used in a generic context except 
being passed to utilities that copy the bytes out. That will either be done by 
directly iterating over the collection or invoking some other API that could 
take a Sequence. The most important is probably Array.append(contentsOf:), 
which is moving over to Sequence. However, we would also need to change 
UnsafeRawBufferPointer(copyBytes:), NSData(replaceSubrange:), and whatever else 
I haven't thought of. That's a small disadvantage to this solution.

I'm also a little concerned that Sequence is immutable, so generic code has no 
way to copy bytes into the buffer.

My bigger concern is still that the range subscript’s inconsistent behavior may 
still lead to bugs in practice in nongeneric code.

-Andy___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> 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 
>> single-pass. So if this is important, it needs to stay a Collection.
>> 
> 
> Just because something fulfills one of the requirements of a Collection does 
> not mean it should be one. It needs to tick all the boxes before its allowed 
> to be elevated.
> 
> But it’s still allowed to have subscripts (UnsafePointer has subscripting but 
> isn’t a collection) or be multi-pass (strides are multiples but are only 
> sequences). That’s OK
> 
> In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t a 
> collection because it doesn’t meet the requirements for slicing i.e. that 
> indices of the slice be indices of the parent.
> (relatedly… it appears this requirement is documented on the concrete Slice 
> type rather than on Collection… which is a documentation bug we should fix).

Ah, right, thank you. Retracted.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

> 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 requirements of a Collection does 
not mean it should be one. It needs to tick all the boxes before its allowed to 
be elevated.

But it’s still allowed to have subscripts (UnsafePointer has subscripting but 
isn’t a collection) or be multi-pass (strides are multiples but are only 
sequences). That’s OK

In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t a 
collection because it doesn’t meet the requirements for slicing i.e. that 
indices of the slice be indices of the parent.
(relatedly… it appears this requirement is documented on the concrete Slice 
type rather than on Collection… which is a documentation bug we should fix).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Generic types—covariance/contravariance

[Braeden Profile via swift-evolution]

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 fails—but that only 
lessens the impact of the missing functionality.  This is my exact use case 
here, using SceneKit to identify the first-hit Controller object:

class ControllerNode: SCNNode
{
let controller: Controller
}

// Ordered front to back, returns the first Controller object.
for hit in hitTest
{
// Determine if this node is part of a controller.
let ancestrySequence = sequence(first: hit.node, next: { $0.parent })
let lastControllerNode: ControllerNode? = 
ancestrySequence.reduce(nil)
{ ($1 as? ControllerNode) ?? $0 }

if let cabinet = lastControllerNode?.controller as? CabinetController
{ return cabinet }

if let wall = lastControllerNode?.controller as? WallController
{ return wall }
}

This compiles, but unfortunately, this will never work.  The `reduce` algorithm 
always ends up trying to convert things like `ControllerNode as 
ControllerNode`, which—unintuitively—always fails.  Without compiler 
help, so would things like `myIntArray as [Any]` or `Optional(Boy()) as 
Optional`.

If Swift is supposed to welcome generic programming, this would be a great 
thing to have.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> 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.. 
> I think Sequence is sufficient for that purpose.

Um, Sequence doesn’t have a subscript (or indexes). Sequences are single-pass. 
So if this is important, it needs to stay a Collection.

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrew Trick via swift-evolution]

> 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
 >
 wrote:
>> 
 
> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution
> >
> wrote:
> 
> 3) Make all buffer pointers their own slices but use a different
> index type. If the indices were just wrapped pointers, that would
> handle the index sharing without needing an additional property on
> the buffer. We could also maintain integer-based stridable
> conformance (which greatly simplifies index arithmetic), since the
> indices would just offset by a byte for raw buffers or a stride
> for typed buffers.
> 
 
 Unfortunately, switching to non-integer indices would change this
 from being mildly source-breaking to being extremely
 source-breaking, as there’s lots of code out there using buffers
 today indexing them with integers (including integer literals).
 
 The big win with UnsafeBufferPointer having an integer index is
 it’s a drop-in replacement for arrays, so when you hit a
 performance problem using an array you can quickly switch to using
 a buffer under most circumstances instead without having to change
 much of your code – including code that uses for i in
 0..>> 
>>> It is definitely very source-breaking, though with relatively simple fixits:
>>> 
>>> buf[0] ---> buf[buf.startIndex]
>>> buf[3] ---> buf[buf.startIndex + 3]
>>> buf[i] ---> buf[buf.startIndex + i]
>>> 
>>> Any integer arithmetic happening outside the subscript could be left
>>> unchanged. If that cost isn't worth the benefit, then making
>>> UnsafeRawBufferPointer use Slice as its slice type is probably the
>>> best way to resolve that issue.
>>> 
>>> Nate
>> 
>> The fixits aren’t quite that simple for slices, though:
>> 
>>  let slice = buf[3..<6]
>>  slice[3] —> slice[slice.startIndex + 0] // fixit would somehow need to 
>> know this is 0 not 3
>>  slice[i] —> slice[slice.startIndex + ??] // or even need to
>> know this is, erm, I haven’t had enough coffee this morning
>> 
>> The other downside is it would thwart speculatively switching an Array
>> to an UnsafeBuffer to see if that was a bottleneck, then switching
>> back.
>> 
>>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution 
>>>  wrote:
>>> 
>>> 1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.
>>> 
>> 
>> Based on the above, it seems like this is the least bad option, and we
>> need to do this ASAP as currently UnsafeRawBufferPointer is
>> non-compliant with the requirements of slicing and needs changing
>> before it’s more widely adopted.
> 
> Or we could say that UnsafeRawBufferPointer isn't a Collection.  Making
> it a Collection in the first place has always seemed suspect to me.
> 
> -- 
> -Dave

UnsafeRawBufferPointer does not need to be a Collection, but should at least be 
a Sequence. It is a Collection now simply because it fits the criteria 
(nondestructively accessed and subscriptable).

In practice, it needs to be able to interoperate with [UInt8] and be 
interchangeable in the same generic context.

e.g. `byteBuffer += rawBuffer[payloadIndex.. out-of-bounds

To some extent, this ship has sailed. I can see a few of options now:

1. We make UnsafeRawBufferPointer a Sequence and just live with that 
inconsistency. Users need discern the importance of range subscript's 

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

[Xiaodi Wu via swift-evolution]

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 via swift-evolution <
> swift-evolution@swift.org> 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
> > >
> > wrote:
> >>>
> >
> >> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution
> >> >
> >> wrote:
> >>
> >> 3) Make all buffer pointers their own slices but use a different
> >> index type. If the indices were just wrapped pointers, that would
> >> handle the index sharing without needing an additional property on
> >> the buffer. We could also maintain integer-based stridable
> >> conformance (which greatly simplifies index arithmetic), since the
> >> indices would just offset by a byte for raw buffers or a stride
> >> for typed buffers.
> >>
> >
> > Unfortunately, switching to non-integer indices would change this
> > from being mildly source-breaking to being extremely
> > source-breaking, as there’s lots of code out there using buffers
> > today indexing them with integers (including integer literals).
> >
> > The big win with UnsafeBufferPointer having an integer index is
> > it’s a drop-in replacement for arrays, so when you hit a
> > performance problem using an array you can quickly switch to using
> > a buffer under most circumstances instead without having to change
> > much of your code – including code that uses for i in
> > 0.. > wild. Switching to an opaque index would break anyone doing that.
> 
>  It is definitely very source-breaking, though with relatively simple
> fixits:
> 
> buf[0] ---> buf[buf.startIndex]
> buf[3] ---> buf[buf.startIndex + 3]
> buf[i] ---> buf[buf.startIndex + i]
> 
>  Any integer arithmetic happening outside the subscript could be left
>  unchanged. If that cost isn't worth the benefit, then making
>  UnsafeRawBufferPointer use Slice as its slice type is probably the
>  best way to resolve that issue.
> 
>  Nate
> >>>
> >>> The fixits aren’t quite that simple for slices, though:
> >>>
> >>>let slice = buf[3..<6]
> >>>slice[3] —> slice[slice.startIndex + 0] // fixit would somehow need
> to know this is 0 not 3
> >>>slice[i] —> slice[slice.startIndex + ??] // or even need to
> >>> know this is, erm, I haven’t had enough coffee this morning
> >>>
> >>> The other downside is it would thwart speculatively switching an Array
> >>> to an UnsafeBuffer to see if that was a bottleneck, then switching
> >>> back.
> >>>
>  On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.
> 
> >>>
> >>> Based on the above, it seems like this is the least bad option, and we
> >>> need to do this ASAP as currently UnsafeRawBufferPointer is
> >>> non-compliant with the requirements of slicing and needs changing
> >>> before it’s more widely adopted.
> >>
> >> Or we could say that UnsafeRawBufferPointer isn't a Collection.  Making
> >> it a Collection in the first place has always seemed suspect to me.
> >>
> >
> > If this is considered a viable option, it's the one I want. Passing
> > types without bounds checks into generic "safe" code shouldn't be this
> > easy.
>
> I don't think I agree, but that's a separate argument, about
> UnsafeBufferPointer.  This is about passing *untyped* memory without
> bounds checks.
>
> > You should need to explicitly wrap it up in something safe. And I
> > really don't want the known-to-be-error-prone indexing model in
> > concrete unsafe code.
>
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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  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
>> >
>> wrote:
>> 
>> 3) Make all buffer pointers their own slices but use a different
>> index type. If the indices were just wrapped pointers, that would
>> handle the index sharing without needing an additional property on
>> the buffer. We could also maintain integer-based stridable
>> conformance (which greatly simplifies index arithmetic), since the
>> indices would just offset by a byte for raw buffers or a stride
>> for typed buffers.
>> 
> 
> Unfortunately, switching to non-integer indices would change this
> from being mildly source-breaking to being extremely
> source-breaking, as there’s lots of code out there using buffers
> today indexing them with integers (including integer literals).
> 
> The big win with UnsafeBufferPointer having an integer index is
> it’s a drop-in replacement for arrays, so when you hit a
> performance problem using an array you can quickly switch to using
> a buffer under most circumstances instead without having to change
> much of your code – including code that uses for i in
> 0.. wild. Switching to an opaque index would break anyone doing that.
 
 It is definitely very source-breaking, though with relatively simple 
 fixits:
 
buf[0] ---> buf[buf.startIndex]
buf[3] ---> buf[buf.startIndex + 3]
buf[i] ---> buf[buf.startIndex + i]
 
 Any integer arithmetic happening outside the subscript could be left
 unchanged. If that cost isn't worth the benefit, then making
 UnsafeRawBufferPointer use Slice as its slice type is probably the
 best way to resolve that issue.
 
 Nate
>>> 
>>> The fixits aren’t quite that simple for slices, though:
>>> 
>>>let slice = buf[3..<6]
>>>slice[3] —> slice[slice.startIndex + 0] // fixit would somehow need to 
>>> know this is 0 not 3
>>>slice[i] —> slice[slice.startIndex + ??] // or even need to
>>> know this is, erm, I haven’t had enough coffee this morning
>>> 
>>> The other downside is it would thwart speculatively switching an Array
>>> to an UnsafeBuffer to see if that was a bottleneck, then switching
>>> back.
>>> 
 On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution 
  wrote:
 
 1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.
 
>>> 
>>> Based on the above, it seems like this is the least bad option, and we
>>> need to do this ASAP as currently UnsafeRawBufferPointer is
>>> non-compliant with the requirements of slicing and needs changing
>>> before it’s more widely adopted.
>> 
>> Or we could say that UnsafeRawBufferPointer isn't a Collection.  Making
>> it a Collection in the first place has always seemed suspect to me.
>> 
>
> If this is considered a viable option, it's the one I want. Passing
> types without bounds checks into generic "safe" code shouldn't be this
> easy. 

I don't think I agree, but that's a separate argument, about
UnsafeBufferPointer.  This is about passing *untyped* memory without
bounds checks.

> You should need to explicitly wrap it up in something safe. And I
> really don't want the known-to-be-error-prone indexing model in
> concrete unsafe code.


-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alexis Beingessner via swift-evolution]

> 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
 >
 wrote:
>> 
 
> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution
> >
> wrote:
> 
> 3) Make all buffer pointers their own slices but use a different
> index type. If the indices were just wrapped pointers, that would
> handle the index sharing without needing an additional property on
> the buffer. We could also maintain integer-based stridable
> conformance (which greatly simplifies index arithmetic), since the
> indices would just offset by a byte for raw buffers or a stride
> for typed buffers.
> 
 
 Unfortunately, switching to non-integer indices would change this
 from being mildly source-breaking to being extremely
 source-breaking, as there’s lots of code out there using buffers
 today indexing them with integers (including integer literals).
 
 The big win with UnsafeBufferPointer having an integer index is
 it’s a drop-in replacement for arrays, so when you hit a
 performance problem using an array you can quickly switch to using
 a buffer under most circumstances instead without having to change
 much of your code – including code that uses for i in
 0..>> 
>>> It is definitely very source-breaking, though with relatively simple fixits:
>>> 
>>>buf[0] ---> buf[buf.startIndex]
>>>buf[3] ---> buf[buf.startIndex + 3]
>>>buf[i] ---> buf[buf.startIndex + i]
>>> 
>>> Any integer arithmetic happening outside the subscript could be left
>>> unchanged. If that cost isn't worth the benefit, then making
>>> UnsafeRawBufferPointer use Slice as its slice type is probably the
>>> best way to resolve that issue.
>>> 
>>> Nate
>> 
>> The fixits aren’t quite that simple for slices, though:
>> 
>>let slice = buf[3..<6]
>>slice[3] —> slice[slice.startIndex + 0] // fixit would somehow need to 
>> know this is 0 not 3
>>slice[i] —> slice[slice.startIndex + ??] // or even need to
>> know this is, erm, I haven’t had enough coffee this morning
>> 
>> The other downside is it would thwart speculatively switching an Array
>> to an UnsafeBuffer to see if that was a bottleneck, then switching
>> back.
>> 
>>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution 
>>>  wrote:
>>> 
>>> 1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.
>>> 
>> 
>> Based on the above, it seems like this is the least bad option, and we
>> need to do this ASAP as currently UnsafeRawBufferPointer is
>> non-compliant with the requirements of slicing and needs changing
>> before it’s more widely adopted.
> 
> Or we could say that UnsafeRawBufferPointer isn't a Collection.  Making
> it a Collection in the first place has always seemed suspect to me.
> 

If this is considered a viable option, it's the one I want. Passing types 
without bounds checks into generic "safe" code shouldn't be this easy. You 
should need to explicitly wrap it up in something safe. And I really don't want 
the known-to-be-error-prone indexing model in concrete unsafe code.

> -- 
> -Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 Cook via swift-evolution
 >
 wrote:
 
 3) Make all buffer pointers their own slices but use a different
 index type. If the indices were just wrapped pointers, that would
 handle the index sharing without needing an additional property on
 the buffer. We could also maintain integer-based stridable
 conformance (which greatly simplifies index arithmetic), since the
 indices would just offset by a byte for raw buffers or a stride
 for typed buffers.
 
>>> 
>>> Unfortunately, switching to non-integer indices would change this
>>> from being mildly source-breaking to being extremely
>>> source-breaking, as there’s lots of code out there using buffers
>>> today indexing them with integers (including integer literals).
>>> 
>>> The big win with UnsafeBufferPointer having an integer index is
>>> it’s a drop-in replacement for arrays, so when you hit a
>>> performance problem using an array you can quickly switch to using
>>> a buffer under most circumstances instead without having to change
>>> much of your code – including code that uses for i in
>>> 0..>> wild. Switching to an opaque index would break anyone doing that.
>> 
>> It is definitely very source-breaking, though with relatively simple fixits:
>> 
>>  buf[0] ---> buf[buf.startIndex]
>>  buf[3] ---> buf[buf.startIndex + 3]
>>  buf[i] ---> buf[buf.startIndex + i]
>> 
>> Any integer arithmetic happening outside the subscript could be left
>> unchanged. If that cost isn't worth the benefit, then making
>> UnsafeRawBufferPointer use Slice as its slice type is probably the
>> best way to resolve that issue.
>> 
>> Nate
>
> The fixits aren’t quite that simple for slices, though:
>
>   let slice = buf[3..<6]
>   slice[3] —> slice[slice.startIndex + 0] // fixit would somehow need to 
> know this is 0 not 3
>   slice[i] —> slice[slice.startIndex + ??] // or even need to
> know this is, erm, I haven’t had enough coffee this morning
>
> The other downside is it would thwart speculatively switching an Array
> to an UnsafeBuffer to see if that was a bottleneck, then switching
> back.
>
>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution 
>>  wrote:
>> 
>> 1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.
>> 
>
> Based on the above, it seems like this is the least bad option, and we
> need to do this ASAP as currently UnsafeRawBufferPointer is
> non-compliant with the requirements of slicing and needs changing
> before it’s more widely adopted.

Or we could say that UnsafeRawBufferPointer isn't a Collection.  Making
it a Collection in the first place has always seemed suspect to me.

-- 
-Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

> 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 UnsafeMutablePointer.initialize(from:) to 
>> UnsafeMutableBufferPointer" begins now and runs through December 12, 2016. 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0147-move-unsafe-initialize-from.md
>>  
>> 
> extension UnsafeMutableBufferPointer {
>   /// Initializes memory in the buffer with the elements of `source`.
>   /// Returns an iterator to any elements of `source` that didn't fit in the 
>   /// buffer, and an index to the point in the buffer one past the last 
> element
>   /// written (so `startIndex` if no elements written, `endIndex` if the 
> buffer 
>   /// was completely filled).
>   ///
>   /// - Precondition: The memory in `self` is uninitialized. The buffer must 
> contain
>   ///   sufficient uninitialized memory to accommodate 
> `source.underestimatedCount`.
>   ///
>   /// - Postcondition: The returned iterator
>   /// - Postcondition: The `Pointee`s at `self[startIndex..   ///   are initialized.
> 
> 
> It looks like the first postcondition got cut off.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Thanks Alex, sorry about that. This should probably read “The returned iterator 
will yield any remaining elements of the sequence not written to the buffer”. 
I’m not sure if this really needs to be a postcondition though, in addition to 
being the documented behavior of the return value.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

> 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 
>>> > wrote:
>>> 
>>> 3) Make all buffer pointers their own slices but use a different index 
>>> type. If the indices were just wrapped pointers, that would handle the 
>>> index sharing without needing an additional property on the buffer. We 
>>> could also maintain integer-based stridable conformance (which greatly 
>>> simplifies index arithmetic), since the indices would just offset by a byte 
>>> for raw buffers or a stride for typed buffers.
>>> 
>> 
>> Unfortunately, switching to non-integer indices would change this from being 
>> mildly source-breaking to being extremely source-breaking, as there’s lots 
>> of code out there using buffers today indexing them with integers (including 
>> integer literals).
>> 
>> The big win with UnsafeBufferPointer having an integer index is it’s a 
>> drop-in replacement for arrays, so when you hit a performance problem using 
>> an array you can quickly switch to using a buffer under most circumstances 
>> instead without having to change much of your code – including code that 
>> uses for i in 0..> wild. Switching to an opaque index would break anyone doing that.
> 
> It is definitely very source-breaking, though with relatively simple fixits:
> 
>   buf[0] ---> buf[buf.startIndex]
>   buf[3] ---> buf[buf.startIndex + 3]
>   buf[i] ---> buf[buf.startIndex + i]
> 
> Any integer arithmetic happening outside the subscript could be left 
> unchanged. If that cost isn't worth the benefit, then making 
> UnsafeRawBufferPointer use Slice as its slice type is probably the best way 
> to resolve that issue.
> 
> Nate



The fixits aren’t quite that simple for slices, though:

let slice = buf[3..<6]
slice[3] —> slice[slice.startIndex + 0] // fixit would somehow need to 
know this is 0 not 3
slice[i] —> slice[slice.startIndex + ??] // or even need to know this 
is, erm, I haven’t had enough coffee this morning

The other downside is it would thwart speculatively switching an Array to an 
UnsafeBuffer to see if that was a bottleneck, then switching back.

> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution 
>  wrote:
> 
> 1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.
> 

Based on the above, it seems like this is the least bad option, and we need to 
do this ASAP as currently UnsafeRawBufferPointer is non-compliant with the 
requirements of slicing and needs changing before it’s more widely adopted.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gonçalo Alvarez Peixoto via swift-evolution]

@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 based on all the fine arguments raised by everyone
during the discussion, however we have not found time to complete it. We
will definitely keep in touch in the following days. I believe your
proposal really relates to ours. The real urge is to revisit access level
controls, if need it be, and create finer grained modifiers for better
communication.

@Derrick

This being said, the solution might even reduce the number of access
control modifiers and not just add one more to the pile. I think we all aim
to have the right amount of modifiers for the right amount of use cases.
Should they be organised and designed in a way that better conveys their
intent, then I believe the number will not be the number one problem.

@Tino

I do agree with you. It is sometimes hard to keep track of all the
proposals/discussions being raised. While I do believe this is an open
enough forum for everyone to participate in, it can become quite hard to
have the full spectrum of discussions in sight at first glance.

Best,
Gonçalo

2016-12-08 18:51 GMT+00:00 Tino Heth <2...@gmx.de>:

> 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 invitation I have looked over the thread for his proposal
> and I am withdrawing my request and backing his with a very heavy +1.
> This one? https://github.com/goncaloalvarez/swift-evolution/blob/master/
> proposals/-introduce-typeprivate-access-control-level.md
>
> > If I have offended anyone I ask their forgiveness. Since you mentioned
> it I will state that the Xcode approach to project groups is one that I
> have yet to understand the merit of.
> > Gonzalo: please let me know how I can assist you.
> I don't think anyone is offended, and imho your offer to Gonzalo is a good
> move (it's just sad that there is no established tool for such
> collaboration)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

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 invitation I have looked over the thread for his proposal and I 
> am withdrawing my request and backing his with a very heavy +1. 
This one? 
https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/-introduce-typeprivate-access-control-level.md

> If I have offended anyone I ask their forgiveness. Since you mentioned it I 
> will state that the Xcode approach to project groups is one that I have yet 
> to understand the merit of. 
> Gonzalo: please let me know how I can assist you.
I don't think anyone is offended, and imho your offer to Gonzalo is a good move 
(it's just sad that there is no established tool for such collaboration)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alex Martini via swift-evolution]

> 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:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0147-move-unsafe-initialize-from.md
>  
> 
extension UnsafeMutableBufferPointer {
  /// Initializes memory in the buffer with the elements of `source`.
  /// Returns an iterator to any elements of `source` that didn't fit in the 
  /// buffer, and an index to the point in the buffer one past the last element
  /// written (so `startIndex` if no elements written, `endIndex` if the buffer 
  /// was completely filled).
  ///
  /// - Precondition: The memory in `self` is uninitialized. The buffer must 
contain
  ///   sufficient uninitialized memory to accommodate 
`source.underestimatedCount`.
  ///
  /// - Postcondition: The returned iterator
  /// - Postcondition: The `Pointee`s at `self[startIndex..

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

[Derrick Ho via swift-evolution]

-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 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 development of
> Swift. Though this email approach may cause some problems, all of you have
> advanced the language tremendously in a very short period of time.
> If I have offended anyone I ask their forgiveness. Since you mentioned it
> I will state that the Xcode approach to project groups is one that I have
> yet to understand the merit of.
> Gonzalo: please let me know how I can assist you.
> - Jim
>
> _
> From: Tino Heth <2...@gmx.de>
> Sent: Thursday, December 8, 2016 12:08 PM
>
> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a
> compliment to fileprivate?
> To: Jim Malak 
> Cc: 
>
>
> 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
>
> b) The tool used for discussion (mailing list) is broken** as well
>
> Right now, I'm in the mood to write a rant about b) (that might change
> until I have time to do so ;-), but returning back to topic, I really don't
> think adding more and more levels with more and more magic words is a bad
> idea.
> Additionally, "directoryprivate" will be really painful due to the way
> Xcode deals with the filesystem (although that might be an argument for
> adding it, as imho Xcode needs improvement in this aspect anyways ;-)
>
> - Tino
>
> * three things to be honest; but the last one would be to controversial
> for a half sentence without explanation
>
> ** actually, I think "broken" is way to hard — but judging from past
> experience, I come to the sad conclusion that provoking statements are
> better to drive discussion ;-)
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jim Malak via swift-evolution]

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 development of Swift. 
Though this email approach may cause some problems, all of you have advanced 
the language tremendously in a very short period of time.
If I have offended anyone I ask their forgiveness. Since you mentioned it I 
will state that the Xcode approach to project groups is one that I have yet to 
understand the merit of.
Gonzalo: please let me know how I can assist you.
- Jim

_
From: Tino Heth <2...@gmx.de>
Sent: Thursday, December 8, 2016 12:08 PM
Subject: Re: [swift-evolution] Any consideration for directoryprivate as a 
compliment to fileprivate?
To: Jim Malak >
Cc: >


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

b) The tool used for discussion (mailing list) is broken** as well

Right now, I'm in the mood to write a rant about b) (that might change until I 
have time to do so ;-), but returning back to topic, I really don't think 
adding more and more levels with more and more magic words is a bad idea.
Additionally, "directoryprivate" will be really painful due to the way Xcode 
deals with the filesystem (although that might be an argument for adding it, as 
imho Xcode needs improvement in this aspect anyways ;-)

- Tino

* three things to be honest; but the last one would be to controversial for a 
half sentence without explanation

** actually, I think "broken" is way to hard - but judging from past 
experience, I come to the sad conclusion that provoking statements are better 
to drive discussion ;-)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vincent Jousse via swift-evolution]

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
 
)
 has not been updated and commands to use old swift 2 code 
(dispatch_source_create( DISPATCH_SOURCE_TYPE_TIMER, 0, 0, some_dispatch_queue 
)).
Is creating a timer source with DispatchSource.makeTimerSource() and casting it 
to DispatchSource the right way to go ?

Vincent___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jeremy Pereira via swift-evolution]

> 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:
> 
> "fileprivate" is needed for certain things like Equatable since the equatable 
> function might need to know about private properties in a class. Lets say I 
> have two structs:
> 
> struct A {
> ...
> }
> 
> struct B {
> ...
> }
> 
> Both are rather big so I declare each in a separate file (File A, File B), 
> but I need to implement an equals function between these two structs that 
> need access to private properties in both structs. This leaves me with two 
> options:
> 
> a) Move the two structs into one file and use fileprivate and implement the 
> equals function here. The result is one long messy file.
> b) Move the two files into a separate module and use "internal" for the 
> variables I need acces to. This feels like overkill and struct A/B might have 
> dependencies that make this inconvenient.
> 
> Am I missing a more optimal solution here? 

To conform to Equatable, the arguments to == need to have the same type.

However there might be other operators for which you might conceivably want to 
do this. I think the right long term answer to this is submodules and submodule 
visibility. For the present, I would argue that a source file isn’t messy just 
because it is long. So I’d put them in the same file or raise the read 
visibility of the properties the operator depends on to internal.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

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

b) The tool used for discussion (mailing list) is broken** as well

Right now, I'm in the mood to write a rant about b) (that might change until I 
have time to do so ;-), but returning back to topic, I really don't think 
adding more and more levels with more and more magic words is a bad idea.
Additionally, "directoryprivate" will be really painful due to the way Xcode 
deals with the filesystem (although that might be an argument for adding it, as 
imho Xcode needs improvement in this aspect anyways ;-)

- Tino

* three things to be honest; but the last one would be to controversial for a 
half sentence without explanation

** actually, I think "broken" is way to hard — but judging from past 
experience, I come to the sad conclusion that provoking statements are better 
to drive discussion ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Aron Lindberg via swift-evolution]

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 go back to my long swift files and fileprivate now ;)

/Aron

> On 8 Dec 2016, at 14.05, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> 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 A is allowed to be conformed to from module B
> public protocol from module A can only be used as an interface in module B
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 13:52:27, Aron Lindberg (ar...@me.com 
> ) schrieb:
> 
>> 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 private properties in a class. 
>> Lets say I have two structs: 
>> 
>> struct A { 
>> ... 
>> } 
>> 
>> struct B { 
>> ... 
>> } 
>> 
>> Both are rather big so I declare each in a separate file (File A, File B), 
>> but I need to implement an equals function between these two structs that 
>> need access to private properties in both structs. This leaves me with two 
>> options: 
>> 
>> a) Move the two structs into one file and use fileprivate and implement the 
>> equals function here. The result is one long messy file. 
>> b) Move the two files into a separate module and use "internal" for the 
>> variables I need acces to. This feels like overkill and struct A/B might 
>> have dependencies that make this inconvenient. 
>> 
>> Am I missing a more optimal solution here?  
>> 
>> My point is there are legit use cases of fileprivate there might lead to one 
>> really big file, with several classes. Having a folderprivate access level 
>> would be one possible solution to this. 
>> 
>> > On 8 Dec 2016, at 13.22, Rien via swift-evolution 
>> >  wrote: 
>> >  
>> > 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 
>> >>  wrote: 
>> >>  
>> >> 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 
>>   wrote: 
>>   
>>  Whoops I meant directoryprivate not dictionaryprivate. I’m probably 
>>  still sleepy.  
>>   
>>   
>>   
>>   
>>  --  
>>  Adrian Zubarev 
>>  Sent with Airmail 
>>   
>>  Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
>>  (adrian.zuba...@devandartist.com) schrieb: 
>>   
>> > You haven’t seen this in the list because no one requested 
>> > dictionaryprivate yet. :D 
>> >  
>> > @core-team: See what you have done with >>file<> > typerprivate, typepublic all these requests for new access modifiers.  
>> >  
>> > Instead of just going with 
>> >  
>> > private 
>> > private(file) 
>> >  
>> > // for new one  
>> > private(type) 
>> >  
>> > I know there would be some people that would forget about (file/type) 
>> > and write only private everywhere, which is probably the main reason 
>> > why we have fileprivate now. 
>> >  
>> > Anyways let’s be a little more constructive here. 
>> >  
>> > Hi Jim, regarding your request, it feels like this is something that 
>> > falls into the topic of submodules. :) Correct me if I’m wrong here. 
>> >  
>> >  
>> >  
>> > --  
>> > Adrian Zubarev 
>> > Sent with Airmail 
>> >  
>> > Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
>> > (swift-evolution@swift.org) schrieb: 
>> >  
>> >> My apologies up front if I am going about this incorrectly. I have 
>> >> been exploring extensions in Swift 3 both as a part of 
>> >> protocol-oriented programming and as a way to encapsulate related 
>> 

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

[Jim Malak via swift-evolution]

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 situation worse. I do want to be able 
have encapsulation in an extension that can be shared in a group that is easy 
to define and to perceive. Adrian had mentioned an idea that, if I understood 
it correctly, was based on some modifier to the AC of private.

I can appreciate that what I suggested as a solution may not be well received 
but I would like to elevate this up to the question of: "Is there support in 
the community for a way of having properties and methods marked as only 
accessible between a group of related extensions  and the object type that they 
are extending?"

- Jim
_
From: Saagar Jha >
Sent: Thursday, December 8, 2016 7:55 AM
Subject: Re: [swift-evolution] Any consideration for directoryprivate as a 
compliment to fileprivate?
To: Adrian Zubarev 
>
Cc: swift-evolution 
>, Jim Malak 
>


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 time (I’m up for improvements, but I fear that it’s 
too late to change now). The issue with directoryprivate/folderprivate is that 
it takes these issues from fileprivate and compounds across many files. With 
one file it’s easy to figure out what’s going on, but once you have a more than 
a few than keeping track of access between them becomes a pain.

Saagar Jha



On Dec 8, 2016, at 4:38 AM, Adrian Zubarev via swift-evolution 
> wrote:


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, Jim Malak 
(jim.ma...@beryle-lee.com) schrieb:

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc


From: Aron Lindberg >
Sent: Thursday, December 8, 2016 7:34:06 AM
To: Jim Malak
Cc: Adrian Zubarev; swift-evolution@swift.org
Subject: 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 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 keep it simple, to use the underlying file system to decide 
what is a folder. Does that sound ok?

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc


From: Aron Lindberg >
Sent: Thursday, December 8, 2016 6:26:10 AM
To: Adrian Zubarev
Cc: Jim Malak; swift-evolution@swift.org
Subject: 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 Zubarev
Sent with Airmail


Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 

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

[Adrian Zubarev via swift-evolution]

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 A is allowed to be conformed to from module B
public protocol from module A can only be used as an interface in module B


-- 
Adrian Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 13:52:27, Aron Lindberg (ar...@me.com) schrieb:

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 private properties in a class. Lets say I 
have two structs:  

struct A {  
...  
}  

struct B {  
...  
}  

Both are rather big so I declare each in a separate file (File A, File B), but 
I need to implement an equals function between these two structs that need 
access to private properties in both structs. This leaves me with two options:  

a) Move the two structs into one file and use fileprivate and implement the 
equals function here. The result is one long messy file.  
b) Move the two files into a separate module and use "internal" for the 
variables I need acces to. This feels like overkill and struct A/B might have 
dependencies that make this inconvenient.  

Am I missing a more optimal solution here?  

My point is there are legit use cases of fileprivate there might lead to one 
really big file, with several classes. Having a folderprivate access level 
would be one possible solution to this.  

> On 8 Dec 2016, at 13.22, Rien via swift-evolution  
> wrote:  
>  
> 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 
>>  wrote:  
>>  
>> 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 
  wrote:  
  
 Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
 sleepy.  
  
  
  
  
 --  
 Adrian Zubarev  
 Sent with Airmail  
  
 Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
 (adrian.zuba...@devandartist.com) schrieb:  
  
> You haven’t seen this in the list because no one requested 
> dictionaryprivate yet. :D  
>  
> @core-team: See what you have done with >>file< typerprivate, typepublic all these requests for new access modifiers.  
>  
> Instead of just going with  
>  
> private  
> private(file)  
>  
> // for new one  
> private(type)  
>  
> I know there would be some people that would forget about (file/type) and 
> write only private everywhere, which is probably the main reason why we 
> have fileprivate now.  
>  
> Anyways let’s be a little more constructive here.  
>  
> Hi Jim, regarding your request, it feels like this is something that 
> falls into the topic of submodules. :) Correct me if I’m wrong here.  
>  
>  
>  
> --  
> Adrian Zubarev  
> Sent with Airmail  
>  
> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
> (swift-evolution@swift.org) schrieb:  
>  
>> My apologies up front if I am going about this incorrectly. I have been 
>> exploring extensions in Swift 3 both as a part of protocol-oriented 
>> programming and as a way to encapsulate related code to improve 
>> readability and maintainablity of otherwise more complex classes I have 
>> designed. I am able to encapsulate methods and calculated properties in 
>> extensions and restrict their use to the object type I am extending as 
>> long as everything is in one file via fileprivate.  
>>  
>> I would like to be able to have my class or structure file in a 
>> directory that contains my associated extensions (also in separate 
>> files) and be able to restrict the access of appropriate properties and 
>> methods to that common directory. This would allow the same level 
>> encapsulation as fileprivate with the benifit of being able to organize 
>> code into sepereate files based on function.  
>>  
>> I did not see this in the commonly rejected list but am unsure if this 

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

[Rien via swift-evolution]

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 operation.

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 13:52, Aron Lindberg  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:
> 
> "fileprivate" is needed for certain things like Equatable since the equatable 
> function might need to know about private properties in a class. Lets say I 
> have two structs:
> 
> struct A {
> ...
> }
> 
> struct B {
> ...
> }
> 
> Both are rather big so I declare each in a separate file (File A, File B), 
> but I need to implement an equals function between these two structs that 
> need access to private properties in both structs. This leaves me with two 
> options:
> 
> a) Move the two structs into one file and use fileprivate and implement the 
> equals function here. The result is one long messy file.
> b) Move the two files into a separate module and use "internal" for the 
> variables I need acces to. This feels like overkill and struct A/B might have 
> dependencies that make this inconvenient.
> 
> Am I missing a more optimal solution here? 
> 
> My point is there are legit use cases of fileprivate there might lead to one 
> really big file, with several classes. Having a folderprivate access level 
> would be one possible solution to this.
> 
>> On 8 Dec 2016, at 13.22, Rien via swift-evolution 
>>  wrote:
>> 
>> 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 
>>>  wrote:
>>> 
>>> 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 
>  wrote:
> 
> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
> sleepy. 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> You haven’t seen this in the list because no one requested 
>> dictionaryprivate yet. :D
>> 
>> @core-team: See what you have done with >>file<> typerprivate, typepublic all these requests for new access modifiers. 
>> 
>> Instead of just going with
>> 
>> private
>> private(file)
>> 
>> // for new one
>> private(type)
>> 
>> I know there would be some people that would forget about (file/type) 
>> and write only private everywhere, which is probably the main reason why 
>> we have fileprivate now.
>> 
>> Anyways let’s be a little more constructive here.
>> 
>> Hi Jim, regarding your request, it feels like this is something that 
>> falls into the topic of submodules. :) Correct me if I’m wrong here.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
>> (swift-evolution@swift.org) schrieb:
>> 
>>> My apologies up front if I am going about this incorrectly. I have been 
>>> exploring extensions in Swift 3 both as a part of protocol-oriented 
>>> programming and as a way to encapsulate related code to improve 
>>> readability and maintainablity of otherwise more complex classes I have 
>>> designed. I am able to encapsulate methods and calculated properties in 
>>> extensions and restrict their use to the object type I am extending as 
>>> long as everything is in one file via fileprivate. 
>>> 
>>> I would like to be able to have my class or structure file in a 
>>> directory that contains my associated extensions  (also in separate 
>>> files) and be able to restrict the access  of appropriate properties 
>>> and  methods to that common directory. This would allow the same level 
>>> encapsulation as fileprivate with the benifit of being able to organize 
>>> code into sepereate files based on function.
>>> 
>>> I did not see this in the commonly rejected list 

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

[Saagar Jha via swift-evolution]

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 time (I’m up for improvements, but I fear that it’s 
too late to change now). The issue with directoryprivate/folderprivate is that 
it takes these issues from fileprivate and compounds across many files. With 
one file it’s easy to figure out what’s going on, but once you have a more than 
a few than keeping track of access between them becomes a pain.

Saagar Jha



> On Dec 8, 2016, at 4:38 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> 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, Jim Malak (jim.ma...@beryle-lee.com 
> ) schrieb:
> 
>> 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 
>> http://beryle-lee.com 
>> http://linkedin.com/in/jamesmalak 
>> https://www.facebook.com/BeryleLeeInc 
>> From: Aron Lindberg 
>> Sent: Thursday, December 8, 2016 7:34:06 AM
>> To: Jim Malak
>> Cc: Adrian Zubarev; swift-evolution@swift.org
>> Subject: 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 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 keep it simple, to use the underlying file system to 
>>> decide what is a folder. Does that sound ok?
>>> 
>>> 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 
>>> http://beryle-lee.com 
>>> http://linkedin.com/in/jamesmalak 
>>> https://www.facebook.com/BeryleLeeInc 
>>> 
>>> From: Aron Lindberg >
>>> Sent: Thursday, December 8, 2016 6:26:10 AM
>>> To: Adrian Zubarev
>>> Cc: Jim Malak; swift-evolution@swift.org 
>>> Subject: 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 Zubarev
 Sent with Airmail
 
 Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
 (adrian.zuba...@devandartist.com ) 
 schrieb:
 
> You haven’t seen this in the list because no one requested 
> dictionaryprivate yet. :D
> 
> @core-team: See what you have done with >>file< typerprivate, typepublic all these requests for new access modifiers. 
> 
> Instead of just going with
> 
> private
> private(file)
> 
> // for new one
> private(type)
> I know there would be some people that would forget about (file/type) and 
> write only private everywhere, which is probably the main reason why we 
> have fileprivate now.
> 
> Anyways let’s be a little more constructive here.
> 
> Hi Jim, regarding your request, it feels like this is something that 
> falls into the topic of submodules. :) Correct me if I’m wrong here.
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 

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

[Aron Lindberg via swift-evolution]

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 private properties in a class. Lets say I 
have two structs:

struct A {
...
}

struct B {
...
}

Both are rather big so I declare each in a separate file (File A, File B), but 
I need to implement an equals function between these two structs that need 
access to private properties in both structs. This leaves me with two options:

a) Move the two structs into one file and use fileprivate and implement the 
equals function here. The result is one long messy file.
b) Move the two files into a separate module and use "internal" for the 
variables I need acces to. This feels like overkill and struct A/B might have 
dependencies that make this inconvenient.

Am I missing a more optimal solution here? 

My point is there are legit use cases of fileprivate there might lead to one 
really big file, with several classes. Having a folderprivate access level 
would be one possible solution to this.

> On 8 Dec 2016, at 13.22, Rien via swift-evolution  
> wrote:
> 
> 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 
>>  wrote:
>> 
>> 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 
  wrote:
 
 Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
 sleepy. 
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
 (adrian.zuba...@devandartist.com) schrieb:
 
> You haven’t seen this in the list because no one requested 
> dictionaryprivate yet. :D
> 
> @core-team: See what you have done with >>file< typerprivate, typepublic all these requests for new access modifiers. 
> 
> Instead of just going with
> 
> private
> private(file)
> 
> // for new one
> private(type)
> 
> I know there would be some people that would forget about (file/type) and 
> write only private everywhere, which is probably the main reason why we 
> have fileprivate now.
> 
> Anyways let’s be a little more constructive here.
> 
> Hi Jim, regarding your request, it feels like this is something that 
> falls into the topic of submodules. :) Correct me if I’m wrong here.
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> My apologies up front if I am going about this incorrectly. I have been 
>> exploring extensions in Swift 3 both as a part of protocol-oriented 
>> programming and as a way to encapsulate related code to improve 
>> readability and maintainablity of otherwise more complex classes I have 
>> designed. I am able to encapsulate methods and calculated properties in 
>> extensions and restrict their use to the object type I am extending as 
>> long as everything is in one file via fileprivate. 
>> 
>> I would like to be able to have my class or structure file in a 
>> directory that contains my associated extensions  (also in separate 
>> files) and be able to restrict the access  of appropriate properties and 
>>  methods to that common directory. This would allow the same level 
>> encapsulation as fileprivate with the benifit of being able to organize 
>> code into sepereate files based on function.
>> 
>> I did not see this in the commonly rejected list but am unsure if this 
>> is something that is out of scope for 4.0. Is this something I can write 
>> up a proposal for? Is there some other approach that I missed that I 
>> should be using instead?
>> 
>> Kind regards,
>> Jim Malak
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> 

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

[T.J. Usiyan via swift-evolution]

-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
> *Cc:* swift-evolution@swift.org
>
> *Subject:* 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, Jim Malak (jim.ma...@beryle-lee.com)
> schrieb:
>
> 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 <(330)%20818-2600>
> M +1-234-716-2658 <(234)%20716-2658>
> F +1-330-818-2560 <(330)%20818-2560>
>
> email/Skype: jim.ma...@beryle-lee.com
> http://beryle-lee.com
> http://linkedin.com/in/jamesmalak
> https://www.facebook.com/BeryleLeeInc
>
> --
> *From:* Aron Lindberg 
> *Sent:* Thursday, December 8, 2016 7:34:06 AM
> *To:* Jim Malak
> *Cc:* Adrian Zubarev; swift-evolution@swift.org
> *Subject:* 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 <
> swift-evolution@swift.org> wrote:
>
> 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 keep it simple, to use the underlying file system to
> decide what is a folder. Does that sound ok?
>
> Kind regards,
> Jim Malak
> Director
> Beryle & Lee, Inc,
> O +1-330-818-2600 <(330)%20818-2600>
> M +1-234-716-2658 <(234)%20716-2658>
> F +1-330-818-2560 <(330)%20818-2560>
>
> email/Skype: jim.ma...@beryle-lee.com
> http://beryle-lee.com
> http://linkedin.com/in/jamesmalak
> https://www.facebook.com/BeryleLeeInc
>
> --
> *From:* Aron Lindberg 
> *Sent:* Thursday, December 8, 2016 6:26:10 AM
> *To:* Adrian Zubarev
> *Cc:* Jim Malak; swift-evolution@swift.org
> *Subject:* 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 <
> swift-evolution@swift.org> wrote:
>
> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still
> sleepy.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev (
> adrian.zuba...@devandartist.com) schrieb:
>
> You haven’t seen this in the list because no one requested
> dictionaryprivate yet. :D
> --
>
> @core-team: See what you have done with >>file< perprivate, typepublic all these requests for new access modifiers. [image:
> facepalm]
>
> Instead of just going with
>
> private
> private(file)
>
> // for new one
> private(type)
>
> I know there would be some people that would forget about (file/type) and
> write only private everywhere, which is probably the main reason why we
> have fileprivate now.
> --
>
> Anyways let’s be a little more constructive here.
>
> Hi Jim, regarding your request, it feels like this is something that falls
> into the topic of *submodules*. :) Correct me if I’m wrong here.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> My apologies up front if I am going about this incorrectly. I have been
> exploring extensions in Swift 3 both as a part of protocol-oriented
> programming and as a way to encapsulate related code to improve readability
> and maintainablity of otherwise more complex classes I have designed. I am
> able to encapsulate methods and calculated properties in extensions and
> restrict their use to the object type I am extending as long as everything
> is in one file via fileprivate.
>
> I would like to be able to have my class or structure file in a directory
> that contains my associated extensions  (also in separate files) and be
> able to restrict the access  of appropriate properties and  methods to that
> common directory. This would allow the same level encapsulation as
> fileprivate with the benifit of being able to organize code into sepereate
> files based on function.
>
> I did 

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

[Jim Malak via swift-evolution]

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?


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, Jim Malak 
(jim.ma...@beryle-lee.com) schrieb:

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc


From: Aron Lindberg 
Sent: Thursday, December 8, 2016 7:34:06 AM
To: Jim Malak
Cc: Adrian Zubarev; swift-evolution@swift.org
Subject: 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 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 keep it simple, to use the underlying file system to decide 
what is a folder. Does that sound ok?

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc


From: Aron Lindberg >
Sent: Thursday, December 8, 2016 6:26:10 AM
To: Adrian Zubarev
Cc: Jim Malak; swift-evolution@swift.org
Subject: 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 Zubarev
Sent with Airmail


Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
(adrian.zuba...@devandartist.com) 
schrieb:

You haven’t seen this in the list because no one requested dictionaryprivate 
yet. :D



@core-team: See what you have done with >>file) schrieb:

My apologies up front if I am going about this incorrectly. I have been 
exploring extensions in Swift 3 both as a part of protocol-oriented programming 
and as a way to encapsulate related code to improve readability and 
maintainablity of otherwise more complex classes I have designed. I am able to 
encapsulate methods and calculated properties in extensions and restrict their 
use to the object type I am extending as long as everything is in one file via 
fileprivate.

I would like to be able to have my class or structure file in a directory that 
contains my associated extensions  (also in separate files) and be able to 
restrict the access  of appropriate properties and  methods to that common 
directory. This would allow the same level encapsulation as fileprivate with 
the benifit of being able to organize code into sepereate files based on 
function.

I did not see this in the commonly rejected list but am unsure if this is 
something that is out of scope for 4.0. Is this something I can write up a 
proposal for? Is there some other approach that I missed that I should be using 
instead?

Kind regards,
Jim Malak


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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, Jim Malak (jim.ma...@beryle-lee.com) schrieb:

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc

From: Aron Lindberg 
Sent: Thursday, December 8, 2016 7:34:06 AM
To: Jim Malak
Cc: Adrian Zubarev; swift-evolution@swift.org
Subject: 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 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 keep it simple, to use the underlying file system to decide 
what is a folder. Does that sound ok?

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc

From: Aron Lindberg 
Sent: Thursday, December 8, 2016 6:26:10 AM
To: Adrian Zubarev
Cc: Jim Malak; swift-evolution@swift.org
Subject: 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 Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

You haven’t seen this in the list because no one requested dictionaryprivate 
yet. :D

@core-team: See what you have done with >>file<

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

[Jim Malak via swift-evolution]

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc


From: Aron Lindberg 
Sent: Thursday, December 8, 2016 7:34:06 AM
To: Jim Malak
Cc: Adrian Zubarev; swift-evolution@swift.org
Subject: 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 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 keep it simple, to use the underlying file system to decide 
what is a folder. Does that sound ok?

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc


From: Aron Lindberg >
Sent: Thursday, December 8, 2016 6:26:10 AM
To: Adrian Zubarev
Cc: Jim Malak; swift-evolution@swift.org
Subject: 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 Zubarev
Sent with Airmail


Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
(adrian.zuba...@devandartist.com) 
schrieb:

You haven't seen this in the list because no one requested dictionaryprivate 
yet. :D



@core-team: See what you have done with >>file) schrieb:

My apologies up front if I am going about this incorrectly. I have been 
exploring extensions in Swift 3 both as a part of protocol-oriented programming 
and as a way to encapsulate related code to improve readability and 
maintainablity of otherwise more complex classes I have designed. I am able to 
encapsulate methods and calculated properties in extensions and restrict their 
use to the object type I am extending as long as everything is in one file via 
fileprivate.

I would like to be able to have my class or structure file in a directory that 
contains my associated extensions  (also in separate files) and be able to 
restrict the access  of appropriate properties and  methods to that common 
directory. This would allow the same level encapsulation as fileprivate with 
the benifit of being able to organize code into sepereate files based on 
function.

I did not see this in the commonly rejected list but am unsure if this is 
something that is out of scope for 4.0. Is this something I can write up a 
proposal for? Is there some other approach that I missed that I should be using 
instead?

Kind regards,
Jim Malak


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Aron Lindberg via swift-evolution]

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 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 keep it simple, to use the underlying file system to 
> decide what is a folder. Does that sound ok?
> 
> 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  
> http://beryle-lee.com  
> http://linkedin.com/in/jamesmalak  
> https://www.facebook.com/BeryleLeeInc 
> From: Aron Lindberg 
> Sent: Thursday, December 8, 2016 6:26:10 AM
> To: Adrian Zubarev
> Cc: Jim Malak; swift-evolution@swift.org
> Subject: 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 Zubarev
>> Sent with Airmail
>> 
>> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
>> (adrian.zuba...@devandartist.com ) 
>> schrieb:
>> 
>>> You haven’t seen this in the list because no one requested 
>>> dictionaryprivate yet. :D
>>> 
>>> @core-team: See what you have done with >>file<>> typerprivate, typepublic all these requests for new access modifiers. 
>>> 
>>> Instead of just going with
>>> 
>>> private
>>> private(file)
>>> 
>>> // for new one   
>>> private(type)
>>> I know there would be some people that would forget about (file/type) and 
>>> write only private everywhere, which is probably the main reason why we 
>>> have fileprivate now.
>>> 
>>> Anyways let’s be a little more constructive here.
>>> 
>>> Hi Jim, regarding your request, it feels like this is something that falls 
>>> into the topic of submodules. :) Correct me if I’m wrong here.
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 My apologies up front if I am going about this incorrectly. I have been 
 exploring extensions in Swift 3 both as a part of protocol-oriented 
 programming and as a way to encapsulate related code to improve 
 readability and maintainablity of otherwise more complex classes I have 
 designed. I am able to encapsulate methods and calculated properties in 
 extensions and restrict their use to the object type I am extending as 
 long as everything is in one file via fileprivate. 
 
 I would like to be able to have my class or structure file in a directory 
 that contains my associated extensions  (also in separate files) and be 
 able to restrict the access  of appropriate properties and  methods to 
 that common directory. This would allow the same level encapsulation as 
 fileprivate with the benifit of being able to organize code into sepereate 
 files based on function.
 
 I did not see this in the commonly rejected list but am unsure if this is 
 something that is out of scope for 4.0. Is this something I can write up a 
 proposal for? Is there some other approach that I missed that I should be 
 using instead?
 
 Kind regards,
 Jim Malak
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jim Malak via swift-evolution]

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 keep it simple, to use the underlying file system to decide 
what is a folder. Does that sound ok?

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
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
https://www.facebook.com/BeryleLeeInc


From: Aron Lindberg 
Sent: Thursday, December 8, 2016 6:26:10 AM
To: Adrian Zubarev
Cc: Jim Malak; swift-evolution@swift.org
Subject: 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 Zubarev
Sent with Airmail


Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
(adrian.zuba...@devandartist.com) 
schrieb:

You haven't seen this in the list because no one requested dictionaryprivate 
yet. :D



@core-team: See what you have done with >>file) schrieb:

My apologies up front if I am going about this incorrectly. I have been 
exploring extensions in Swift 3 both as a part of protocol-oriented programming 
and as a way to encapsulate related code to improve readability and 
maintainablity of otherwise more complex classes I have designed. I am able to 
encapsulate methods and calculated properties in extensions and restrict their 
use to the object type I am extending as long as everything is in one file via 
fileprivate.

I would like to be able to have my class or structure file in a directory that 
contains my associated extensions  (also in separate files) and be able to 
restrict the access  of appropriate properties and  methods to that common 
directory. This would allow the same level encapsulation as fileprivate with 
the benifit of being able to organize code into sepereate files based on 
function.

I did not see this in the commonly rejected list but am unsure if this is 
something that is out of scope for 4.0. Is this something I can write up a 
proposal for? Is there some other approach that I missed that I should be using 
instead?

Kind regards,
Jim Malak


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

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 
>  wrote:
> 
> 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 
>>>  wrote:
>>> 
>>> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
>>> sleepy. 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
>>> (adrian.zuba...@devandartist.com) schrieb:
>>> 
 You haven’t seen this in the list because no one requested 
 dictionaryprivate yet. :D
 
 @core-team: See what you have done with >>file<>>> typerprivate, typepublic all these requests for new access modifiers. 
 
 Instead of just going with
 
 private
 private(file)
 
 // for new one
 private(type)
 
 I know there would be some people that would forget about (file/type) and 
 write only private everywhere, which is probably the main reason why we 
 have fileprivate now.
 
 Anyways let’s be a little more constructive here.
 
 Hi Jim, regarding your request, it feels like this is something that falls 
 into the topic of submodules. :) Correct me if I’m wrong here.
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
 (swift-evolution@swift.org) schrieb:
 
> My apologies up front if I am going about this incorrectly. I have been 
> exploring extensions in Swift 3 both as a part of protocol-oriented 
> programming and as a way to encapsulate related code to improve 
> readability and maintainablity of otherwise more complex classes I have 
> designed. I am able to encapsulate methods and calculated properties in 
> extensions and restrict their use to the object type I am extending as 
> long as everything is in one file via fileprivate. 
> 
> I would like to be able to have my class or structure file in a directory 
> that contains my associated extensions  (also in separate files) and be 
> able to restrict the access  of appropriate properties and  methods to 
> that common directory. This would allow the same level encapsulation as 
> fileprivate with the benifit of being able to organize code into 
> sepereate files based on function.
> 
> I did not see this in the commonly rejected list but am unsure if this is 
> something that is out of scope for 4.0. Is this something I can write up 
> a proposal for? Is there some other approach that I missed that I should 
> be using instead?
> 
> Kind regards,
> Jim Malak
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 
 wrote:

Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
sleepy. 




-- 
Adrian Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

You haven’t seen this in the list because no one requested dictionaryprivate 
yet. :D

@core-team: See what you have done with >>file<

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

[Aron Lindberg via swift-evolution]

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 Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
> (adrian.zuba...@devandartist.com ) 
> schrieb:
> 
>> You haven’t seen this in the list because no one requested dictionaryprivate 
>> yet. :D
>> 
>> @core-team: See what you have done with >>file<> typepublic all these requests for new access modifiers. 
>> 
>> Instead of just going with
>> 
>> private
>> private(file)
>> 
>> // for new one   
>> private(type)
>> I know there would be some people that would forget about (file/type) and 
>> write only private everywhere, which is probably the main reason why we have 
>> fileprivate now.
>> 
>> Anyways let’s be a little more constructive here.
>> 
>> Hi Jim, regarding your request, it feels like this is something that falls 
>> into the topic of submodules. :) Correct me if I’m wrong here.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> My apologies up front if I am going about this incorrectly. I have been 
>>> exploring extensions in Swift 3 both as a part of protocol-oriented 
>>> programming and as a way to encapsulate related code to improve readability 
>>> and maintainablity of otherwise more complex classes I have designed. I am 
>>> able to encapsulate methods and calculated properties in extensions and 
>>> restrict their use to the object type I am extending as long as everything 
>>> is in one file via fileprivate. 
>>> 
>>> I would like to be able to have my class or structure file in a directory 
>>> that contains my associated extensions  (also in separate files) and be 
>>> able to restrict the access  of appropriate properties and  methods to that 
>>> common directory. This would allow the same level encapsulation as 
>>> fileprivate with the benifit of being able to organize code into sepereate 
>>> files based on function.
>>> 
>>> I did not see this in the commonly rejected list but am unsure if this is 
>>> something that is out of scope for 4.0. Is this something I can write up a 
>>> proposal for? Is there some other approach that I missed that I should be 
>>> using instead?
>>> 
>>> Kind regards,
>>> Jim Malak
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution