Re: [swift-evolution] [Pitch] String revision proposal #1

[Félix Cloutier via swift-evolution]

Does it? According to the documentation for the current decodeCString 
, it 
seems to accept an UnsafePointer, not a buffer pointer, and expects the string 
to be null-terminated. Am I missing another overload?

> Le 30 mars 2017 à 17:27, Zach Waldowski via swift-evolution 
>  a écrit :
> 
> On Thu, Mar 30, 2017, at 12:35 PM, Félix Cloutier via swift-evolution wrote:
>> I don't have much non-nitpick issues that I greatly care about; I'm in favor 
>> of this.
>> 
>> My only request: it's currently painful to create a String from a fixed-size 
>> C array. For instance, if I have a pointer to a `struct foo { char name[16]; 
>> }` in Swift where the last character doesn't have to be a NUL, it's hard to 
>> create a String from it. Real-world examples of this are Mach-O LC_SEGMENT 
>> and LC_SEGMENT_64 commands.
>> 
>> 
>> The generally-accepted wisdom  
>> is that you take a pointer to the CChar tuple that represents the fixed-size 
>> array, but this still requires the string to be NUL-terminated. What do we 
>> think of an additional init(cString:) overload that takes an 
>> UnsafeBufferPointer and reads up to the first NUL or the end of the buffer, 
>> whichever comes first?
> 
> Today's String already supports this through 
> `String.decodeCString(_:as:repairingInvalidCodeUnits:)`, passing a buffer 
> pointer.
> 
> Best,
>   Zachary Waldowski
>   z...@waldowski.me 
> 
> 
> 
> ___
> 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] [Returned for Revision] SE-0160: Limiting @objc inference

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md

The re-review of SE-0160 ran from March 21…28, 2017. The feedback was generally 
positive, but several concerns were raised about the migration story required, 
as well as the implication for XCTest and other similar frameworks.  The core 
team has discussed this and has a number of recommendations that Doug will be 
incorporating into the new draft of review.  I will start that immediately to 
get a short re-review of the updated proposal.

Thank you to Doug for his time and effort invested in implementing this, as 
well as developing a robust migration strategy.

-Chris

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

Re: [swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Mar 30, 2017, at 14:56, David Hart via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> I’m working on a proposal for arbitrary precision integer and float literal 
> protocols to complement ExpressibleByIntegerLiteral and 
> ExpressibleByFloatLiteral. I’m looking for feedback and help in verifying the 
> logic - I have doubts about endianness.
> 
> Fire away!
> 
> https://github.com/hartbit/swift-evolution/blob/arbitrary-precision-integer-float-protocol/proposals/-arbitrary-precision-integer-float-literal-protocols.md
> 
> Arbitrary precision integer and float literal procotols
> Proposal: SE-
> Authors: David Hart
> Review Manager: TBD
> Status: TBD
> Introduction
> 
> We propose a pair of protocols extending ExpressibleByIntegerLiteral and 
> ExpressibleByFloatLiteral to allow initializing conforming types with 
> arbitrary precision integer and floating-point literals.
> 
> Motivation
> 
> The current protocols ExpressibleByIntegerLiteral and 
> ExpressibleByFloatLiteral are simple and work well but don't support 
> arbitrary precision literal values. Replacing those protocols is a non-goal 
> as they provide a simple interface for work well for most cases. Therefore, 
> to support initializing big integer and big float types with literal values, 
> we need new protocols.
> 
> Proposed solution
> 
> We propose:
> 
> renaming FloatingPointSign into Sign,
> introducing a ExpressibleByArbitraryPrecisionIntegerLiteral protocol that 
> extends ExpressibleByIntegerLiteral and provides a new arbitrary precision 
> initializer,
> introducing a ExpressibleByArbitraryPrecisionFloatLiteral protocol that 
> extends ExpressibleByFloatLiteral and provides a new arbitrary precision 
> initializer.
> Here is the corresponding code:
> 
> /// The sign of a number.
> public enum Sign : Int {
> 
> /// The sign for a positive value.
> case plus
> 
> /// The sign for a negative value.
> case minus
> }
> 
> /// A type that can be initialized with an arbitrary precision integer 
> literal.
> public protocol ExpressibleByArbitraryPrecisionIntegerLiteral:
> ExpressibleByIntegerLiteral {
> 
> /// Creates an instance initialized with the sign and memory value of the
> /// arbitrary precision integer literal.
> ///
> /// Do not call this initializer directly. Instead, initialize a variable 
> or
> /// constant using an arbitrary precision integer literal. For example:
> ///
> /// let x = 123_456_789_123_456_789_123_456_789
> ///
> /// In this example, the assignment to the `x` constant calls this integer
> /// literal initializer behind the scenes with `sign` as `.plus` and
> /// `buffer` as the memory [0x00661EFD, 0xF2E3B19F7C045F15].
> ///
> /// - Parameters:
> /// sign: The sign of the integer value.
> /// buffer: The memory value of the integer.
> init(sign: Sign, buffer: UnsafeBufferPointer)
> }
> 
> /// A type that can be initialized with an arbitrary precision float literal.
> public protocol ExpressibleByArbitraryPrecisionFloatLiteral:
> ExpressibleByFloatLiteral {
> 
> /// Creates an instance initialized with the sign, exponent and
> /// significand of the arbitrary precision float literal.
> ///
> /// Do not call this initializer directly. Instead, initialize a variable 
> or
> /// constant using an arbitrary precision integer literal. For example:
> ///
> /// let x = 123_456_789_123_456.789_123_456_789
> ///
> /// In this example, the assignment to the `x` constant calls this float
> /// literal initializer behind the scenes with `sign` as `.plus`, 
> `exponent`
> /// as the memory [0x00661EFD, 0xF2E3B19F7C045F15] and 
> `significand`
> /// with value [0x000C].
> ///
> /// - Parameters:
> /// sign: The sign of the integer value.
> /// exponent: The memory value of the exponent.
> /// significand: The memory value of the significand.
> init(
> sign: Sign,
> exponent: UnsafeBufferPointer,
> significand: UnsafeBufferPointer)
> }
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

IIRC, some branches of math don't consider 0 to be positive or negative, so I 
might add a `zero` case in `Sign`.

Also, I'm not sure new protocols are actually necessary. I think I remember 
hearing somewhere that LLVM supports integer literals up to something like 400 
bits? If so, we'd merely need a type that exposes those bytes to set the 
relevant types `IntegerLiteralType` associated type.

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Brent Royal-Gordon via swift-evolution]

> On Mar 30, 2017, at 2:36 PM, Ben Cohen  wrote:
> 
> The big win for Unicode is it is short. We want to encourage people to write 
> their extensions on this protocol. We want people who previously extended 
> String to feel very comfortable extending Unicode. It also helps emphasis how 
> important the Unicode-ness of Swift.String is. I like the idea of 
> Unicode.Collection, but it is a little intimidating and making it even a tiny 
> bit intimidating is worrying to me from an adoption perspective. 

Yeah, I understand why "Collection" might be intimidating. But I think 
"Unicode" would be too—it's opaque enough that people wouldn't be entirely sure 
whether they were extending the right thing.

I did a quick run-through of different language and the 
protocols/interfaces/whatever their string types conform to, but most don't 
seem to have anything that abstracts string types. The only similar things I 
could find were `CharSequence` in Java, `StringLike` in Scala...and `Stringy` 
in Perl 6. And I'm sure you thought you were joking!

Honestly, I'd recommend just going with `StringProtocol` unless you can come up 
with an adjective form you like (`Stringlike`? `Textual`?). It's a bit clumsy, 
but it's crystal clear. Stupid name, but you'll never forget it.

>> I'm a little worried about this because it seems to imply that the protocol 
>> cannot include any mutation operations that aren't in 
>> `RangeReplaceableCollection`. For instance, it won't be possible to include 
>> an in-place `applyTransform` method in the protocol. Do you anticipate that 
>> being an issue? Might it be a good idea to define a parallel `Mutable` or 
>> `RangeReplaceable` protocol?
>> 
> 
> You can always assign to self. Then provide more efficient implementations 
> where RangeReplaceableCollection. We do this elsewhere in the std lib with 
> collections e.g. 
> https://github.com/apple/swift/blob/master/stdlib/public/core/Collection.swift#L1277
>  
> .
> 
> Proliferating protocol combinations is problematic (looking at you, 
> BidirectionalMutableRandomAccessSlice).

Nobody likes proliferation, but in this case it'd be because there genuinely 
were additional semantics that were only available on mutable strings.

(Once upon a time, I think I requested the ability to write `func index(of 
elem: Iterator.Element) -> Index? where Iterator.Element: Equatable`. Could 
such a feature be used for this? `func apply(_ transform: StringTransform, 
reverse: Bool) where Self: RangeReplaceableCollection`?)

>>> The C string interop methods will be updated to those described here: a 
>>> single withCString operation and two init(cString:) constructors, one for 
>>> UTF8 and one for arbitrary encodings.
>> 
>> Sorry if I'm repeating something that was already discussed, but is there a 
>> reason you don't include a `withCString` variant for arbitrary encodings? It 
>> seems like an odd asymmetry.
> 
> Hmm. Is this a common use-case people have? Symmetry for the sake of it 
> doesn’t seem enough. If uncommon, you can do it via an Array that you 
> nul-terminate manually.

Is `init(cString:encoding:)` a common use case? If it is, I'm not sure why the 
opposite wouldn't be.

> Yeah, it’s tempting to make ParseResult general, and the only reason we held 
> off is because we don’t want making sure it’s generally useful to be a 
> distraction.

Understandable.

I wonder if some part of the parsing algorithm could somehow be generalized so 
it was suitable for many purposes and then put on `Collection`, with the 
`UnicodeEncoding` then being passed as a parameter to it. If so, that would 
justify making `ParseResult` a top-level type.

> Ah, yes. Here it is:
> 
> public protocol EncodedScalarProtocol : RandomAccessCollection {
>  init?(_ scalarValue: UnicodeScalar)
>  var utf8: UTF8.EncodedScalar { get }
>  var utf16: UTF16.EncodedScalar { get }
>  var utf32: UTF32.EncodedScalar { get }
> }

What is the `Element` type expected to be here?

I think what's missing is a holistic overview of the encoding system. So, 
please help me write this function:

func unicodeScalars(in data: Data, using 
encoding: Encoding.Type) -> [UnicodeScalar] {
var scalars: [UnicodeScalar] = []

data.withUnsafeBytes { (bytes: 
UnsafePointer<$ParseInputElement>) in
let buffer = UnsafeBufferPointer(start: bytes, count: 
data.count / MemoryLayout<$ParseInputElement>.size)
encoding.parseForward(buffer) { encodedScalar in
let unicodeScalar: UnicodeScalar = 
$doSomething(encodedScalar)
scalars.append(unicodeScalar)
}
}

return scalars
}

What type would I put for $ParseInputElement? What function or initializer do I 
call for 

Re: [swift-evolution] [Pitch] String revision proposal #1

[Zach Waldowski via swift-evolution]

On Thu, Mar 30, 2017, at 12:35 PM, Félix Cloutier via swift-evolution wrote:
> I don't have much non-nitpick issues that I greatly care about; I'm in
> favor of this.
> 

> My only request: it's currently painful to create a String from a fixed-
> size C array. For instance, if I have a pointer to a `struct foo {
> char name[16]; }` in Swift where the last character doesn't have to be
> a NUL, it's hard to create a String from it. Real-world examples of
> this are Mach-O LC_SEGMENT and LC_SEGMENT_64 commands.
> 

> 

> The generally-accepted wisdom[1] is that you take a pointer to the
> CChar tuple that represents the fixed-size array, but this still
> requires the string to be NUL-terminated. What do we think of an
> additional init(cString:) overload that takes an UnsafeBufferPointer
> and reads up to the first NUL or the end of the buffer, whichever
> comes first?


Today's String already supports this through
`String.decodeCString(_:as:repairingInvalidCodeUnits:)`, passing a
buffer pointer.


Best,

  Zachary Waldowski

  z...@waldowski.me








Links:

  1. http://stackoverflow.com/a/27456220/251153
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] String revision proposal #1

[Karimnassar via swift-evolution]

Makes sense. Thanks for the explanation. 

--Karim

> On Mar 30, 2017, at 7:43 PM, Ben Cohen  wrote:
> 
> 
>> On Mar 30, 2017, at 10:05 AM, Karim Nassar via swift-evolution 
>>  wrote:
>> 
>> 
>>> Message: 12
>>> Date: Thu, 30 Mar 2017 12:23:13 +0200
>>> From: Adrian Zubarev 
>>> To: Ben Cohen 
>>> Cc: swift-evolution@swift.org
>>> Subject: Re: [swift-evolution] [Pitch] String revision proposal #1
>>> Message-ID: 
>>> Content-Type: text/plain; charset="utf-8"
>>> 
>>> I haven’t followed the topic and while reading the proposal I found it a 
>>> little confusing that we have inconsistent type names. I’m not a native 
>>> English speaker so that’s might be the main case for my confusion here, so 
>>> I’d appreciate for any clarification. ;-)
>>> 
>>> SubSequence vs. Substring and not SubString.
>>> 
>>> The word substring is an English word, but so is subsequence (I double 
>>> checked here).
>>> 
>>> So where exactly is the issue here? Is it SubSequence which is written in 
>>> camel case or is it Substring which is not?
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>> 
>> 
>> I’d also be curious if StringSlice was considered, since we have already the 
>> well-established and seemingly-parallel ArraySlice.
>> 
> 
> Yup we considered it (I should probably have put it in the Alternatives 
> Considered section). Also considered: having nothing but String.SubSequence. 
> In fact it may be Substring is just a typealias for String.SubSequence, 
> though this would be an implementation detail rather than part of the 
> proposal.
> 
> The current hope (unrelated to String) is that ArraySlice could be 
> eliminated, by introducing some kind of “ContiguouslyStored” protocol and 
> then extending the general Slice when it slices something that conforms to 
> that. But this can’t be done with Substring because of the small string 
> optimization.
> 
> The other difference is there’s no common term of art for a slice of an 
> Array, whereas there is for a slice of a String.
> 
>> —Karim
>> 
>> ___
>> 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] String revision proposal #1

[Xiaodi Wu via swift-evolution]

On Thu, Mar 30, 2017 at 10:38 AM, Ben Cohen  wrote:

>
> On Mar 29, 2017, at 6:59 PM, Xiaodi Wu  wrote:
>
> This looks great. The restored conformances to *Collection will be huge.
>
> Is this to be the first of several or the only major part of the manifesto
> to be delivered in Swift 4?
>
>
> First of several. This lays the ground work for the changes to the
> underlying implementation. Other changes will mostly be additive on top.
>
> Nits on naming: are we calling it Substring or SubString (à la
> SubSequence)?
>
>
> This is venturing into subjective territory, so these are just my feelings
> rather than something definitive (Dave may differ) but:
>
> It should definitely be Substring. My rule of thumb: if you might
> hyphenate it, you can capitalize it. I don’t think anyone spells it
> "sub-string". OTOH one *might* write "sub-sequence". Generally hyphens
> disappear in english as things come into common usage i.e. it used to be
> e-mail but now it’s mostly just email.  Substring is enough of a term of
> art in programming that this has happened. Admittedly, Subsequence is a
> term of art too – unfortunately one that has a different meaning to ours
> ("a sequence that can be derived from another sequence by deleting some
> elements without changing the order of the remaining elements" e.g. 
> is a Subsequence of  – see https://en.wikipedia.org/
> wiki/Subsequence). Even worse, the mathematical term for what we are
> calling a subsequence is a Substring!
>
> If we were change anything, my vote would be to lowercase Subsequence. We
> can typealias SubSequence = Subsequence to aid migration, with a slow burn
> on deprecating it since it’ll be quite a footling deprecation. I don’t know
> if it’s worth it though – the main use of “SubSequence” is currently in
> those pesky where clauses you have to put on all your Collection extensions
> if you want to use slicing, and many of these will be eliminated once we
> have the ability to put where clauses on associated types.
>

I regret bringing this up. `Substring` is totally fine. `SubSequence` is
too. Just wanted to get some clarification that this was the proposed
spelling. I doubt it's worth a whole migration to change the capitalization
of `SubSequence`, which after all prevents the word from being read like
"consequence."

and shouldn't it be UnicodeParsedResult rather than UnicodeParseResult?
>
>
> I think Parse. As in, this is the result of a parse, not these are the
> parsed results (though it does contain parsed results in some cases, but
> not all).
>

Ah, then `UnicodeParsingResult`, maybe? Something about nouning that verb
doesn't sit right. OK, done with bikeshedding.


> On Wed, Mar 29, 2017 at 19:32 Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Swift Evolution,
>
> Below is a pitch for the first part of the String revision. This covers a
> number of changes that would allow the basic internals to be overhauled.
>
> Online version here: https://github.com/airspeedswift/swift-evolution/
> blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-
> StringRevision1.md
>
>
> String Revision: Collection Conformance, C Interop, Transcoding
>
>- Proposal: SE-0161
>- Authors: Ben Cohen , Dave Abrahams
>
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> Introduction
>
> This proposal is to implement a subset of the changes from the Swift 4
> String Manifesto
> .
>
> Specifically:
>
>- Make String conform to BidirectionalCollection
>- Make String conform to RangeReplaceableCollection
>- Create a Substring type for String.SubSequence
>- Create a Unicode protocol to allow for generic operations over both
>types.
>- Consolidate on a concise set of C interop methods.
>- Revise the transcoding infrastructure.
>
> Other existing aspects of String remain unchanged for the purposes of
> this proposal.
> Motivation
>
> This proposal follows up on a number of recommendations found in the
> manifesto:
>
> Collection conformance was dropped from String in Swift 2. After
> reevaluation, the feeling is that the minor semantic discrepancies (mainly
> with RangeReplaceableCollection) are outweighed by the significant
> benefits of restoring these conformances. For more detail on the reasoning,
> see here
> 
>
> While it is not a collection, the Swift 3 string does have slicing
> operations. String is currently serving as its own subsequence, allowing
> substrings to share storage with their “owner”. This can lead to memory
> leaks when small substrings of larger strings are stored long-term (see
> here
> 

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Joe Groff via swift-evolution]

> On Mar 30, 2017, at 1:08 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
>>  • What is your evaluation of the proposal?
> +1
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> Yes
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> Yes
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> Lots of languages have key-paths, but usually they are strings. This adds 
> some type-safety, so that’s nice.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> A quick reading. I also have a couple of questions:
> 
> 1) Can we get keypaths from protocol existentials?
> 
> protocol MyProto {
> var something: Int { get }
> }
> struct MyThing: MyProto { /* … */ }
> 
> let myProtoSomethingKeypath = #keypath(MyProto, .something)
> let value: Int = MyThing()[keypath: myProtoSomethingKeypath]  // seems 
> reasonable, right?

Yeah, that would be a natural thing to support.

> 2) What about if it has associated types?
> 
> let secondElement = #keypath(Collection, .subscript[1])  // if 
> Collection.Iterator.Element had constraints, could we dig in to the instance?
> 
> let _: Int = [1,2,3][keypath: secondElement]
> let _: String = [“a”, “b”, “c”][keypath: secondElement]
> 
> 
> But I’d still +1 the proposal even if was limited to concrete types.
> 
> Also, that brings me to 2 related comments regarding the evolution of the 
> feature:
> 
> 1) It would be nice to allow keypaths of constrained protocol existentials
> 
> let secondElementFirstCharacter = #keypath(Collection where 
> Iterator.Element == String, .subscript[0].characters.first)

These would rely on supporting generalized existentials in the language at 
large.

> 2) It would be nice to be able to get keypaths to members which we don’t know 
> exist. Members and protocol conformances may be retroactively added by 
> 3rd-party code.

You could define a library function that applies a key path to a base value, if 
the base value is castable to the root type of the key path. That might be a 
useful enough thing to absorb into the standard library at some point, but it 
doesn't seem to me like it strictly needs to be part of the core proposal.

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution 
>  wrote:
> 
>> * What is your evaluation of the proposal?
> 
> Good. I'll certainly appreciate the added clarity of knowing which methods 
> are exposed to Objective-C.
> 
> Currently, Swift-only apps are bloated by unnecessary Objective-C thunks. The 
> motivation section says that this will reduce the reduce the binary sizes, 
> which is good, but should we expect not emitting those thunks will also 
> reduce by a bit the compilation times? Perhaps not by much, but I do think it 
> will.
> 
> I'm already littering some projects with plenty of `@nonobjc` annotations 
> because I don't need those thunks. This proposal would allow me to make this 
> cleaner. Perhaps the migrator should remove the `@nonobjc` attributes when 
> they become unnecessary. Actually, would the changes in this proposal make 
> the `@nonobjc` attribute irrelevant?
> 
> I'm a bit worried about the migration though.
> 
> I think it would be reasonable for the migrator to have two settings. A 
> conservative one that adds `@objc ` to all currently implicit `@objc` 
> declarations, to be used when you need to be absolutely certain everything 
> still works. Pruning of extra `@objc` would have to be done manually later, 
> if desired. And the default one that only adds `@objc` when the migrator sees 
> it as necessary.


FWIW, I’ve updated the proposal with a much more extensive discussion of the 
migration story. It incorporates “conservative” and “minimal” approaches, and 
describes how to do the “minimal” approach well. (It’s backed by a prototype 
implementation as well; see the Implementation link at the top”)

- Doug

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Ben Cohen via swift-evolution]

> On Mar 30, 2017, at 10:05 AM, Karim Nassar via swift-evolution 
>  wrote:
> 
> 
>> Message: 12
>> Date: Thu, 30 Mar 2017 12:23:13 +0200
>> From: Adrian Zubarev 
>> To: Ben Cohen 
>> Cc: swift-evolution@swift.org
>> Subject: Re: [swift-evolution] [Pitch] String revision proposal #1
>> Message-ID: 
>> Content-Type: text/plain; charset="utf-8"
>> 
>> I haven’t followed the topic and while reading the proposal I found it a 
>> little confusing that we have inconsistent type names. I’m not a native 
>> English speaker so that’s might be the main case for my confusion here, so 
>> I’d appreciate for any clarification. ;-)
>> 
>> SubSequence vs. Substring and not SubString.
>> 
>> The word substring is an English word, but so is subsequence (I double 
>> checked here).
>> 
>> So where exactly is the issue here? Is it SubSequence which is written in 
>> camel case or is it Substring which is not?
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
> 
> 
> I’d also be curious if StringSlice was considered, since we have already the 
> well-established and seemingly-parallel ArraySlice.
> 

Yup we considered it (I should probably have put it in the Alternatives 
Considered section). Also considered: having nothing but String.SubSequence. In 
fact it may be Substring is just a typealias for String.SubSequence, though 
this would be an implementation detail rather than part of the proposal.

The current hope (unrelated to String) is that ArraySlice could be eliminated, 
by introducing some kind of “ContiguouslyStored” protocol and then extending 
the general Slice when it slices something that conforms to that. But this 
can’t be done with Substring because of the small string optimization.

The other difference is there’s no common term of art for a slice of an Array, 
whereas there is for a slice of a String.

> —Karim
> 
> ___
> 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] Collection Type Element Property Observers

[Brent Royal-Gordon via swift-evolution]

> On Mar 30, 2017, at 1:20 PM, Joshua Alvarado via swift-evolution 
>  wrote:
> 
> I think think the gain of functionality isn't there for the addition of this 
> functionality to be added. There are other ways to implement what you are 
> desiring to do without adding it to Swift language.

For instance, wrap your type in something like this:

struct Recorded {
init(_ base: Base) {
self.base = base
changes = [ Change(newElements: base) ]
}

fileprivate(set) var base: Base
fileprivate(set) var changes: [Change]
}

extension Recorded {
final class Change: Hashable, CustomStringConvertible {
let subrange: Range?
let newElements: [Recorded.Iterator.Element]

init(subrange: Range? = nil, newElements: C)
where C.Iterator.Element == Recorded.Iterator.Element
{
self.subrange = subrange
self.newElements = Array(newElements)
}

static func == (lhs: Change, rhs: Change) -> Bool {
return lhs === rhs
}

var hashValue: Int {
return ObjectIdentifier(self).hashValue
}

var description: String {
if let subrange = subrange {
return "base[\(subrange.description)] = 
\(newElements.description)"
}
else {
return "base = \(newElements.description)"
}
}

func apply(to c: inout Recorded) {
let subrange = self.subrange ?? c.startIndex ..< c.endIndex
c.base.replaceSubrange(subrange, with: newElements)
c.changes.append(self)
}
}

mutating func apply(_ changes: [Change]) {
for change in changes {
change.apply(to: )
}
}

func newChanges(since older: Recorded) -> [Change] {
var changes = self.changes

guard let lastChange = older.changes.last,
   let i = changes.index(of: lastChange) else {
return changes
}

let overlapRange = 0 ... i
precondition(
older.changes.suffix(overlapRange.count) == changes[overlapRange],
"self includes old changes not present in older"
)

changes.removeSubrange(0 ... i)
return changes
}
}

extension Recorded: RangeReplaceableCollection {
subscript(_ i: Base.Index) -> Base.Iterator.Element {
get {
return base[i]
}
set {
replaceSubrange(i ..< index(after: i), with: [newValue])
}
}

func index(after i: Base.Index) -> Base.Index {
return base.index(after: i)
}

var startIndex: Base.Index {
return base.startIndex
}

var endIndex: Base.Index {
return base.endIndex
}

init() {
self.init(Base())
}

mutating func replaceSubrange(_ subrange: Range, with 
newElements: C)
where C : Collection,
C.Iterator.Element == Base.Iterator.Element
{
let change = Change(subrange: subrange, newElements: newElements)
change.apply(to: )
}
}

(This is begging for Swift 4's conditional conformance feature, which would 
allow `Recorded` to conform to `RandomAccessCollection` et.al. if the 
underlying type did.)

Now you have a ready-made change list, and all you need to do is write a 
`didSet` that runs `newChanges(since: oldValue)` on the new value and figures 
out what to do with it. That ought to be faster than a full difference 
calculation from scratch on every `didSet`.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

[David Hart via swift-evolution]

Hello swift-evolution,

I’m working on a proposal for arbitrary precision integer and float literal 
protocols to complement ExpressibleByIntegerLiteral and 
ExpressibleByFloatLiteral. I’m looking for feedback and help in verifying the 
logic - I have doubts about endianness.

Fire away!

https://github.com/hartbit/swift-evolution/blob/arbitrary-precision-integer-float-protocol/proposals/-arbitrary-precision-integer-float-literal-protocols.md
 


Arbitrary precision integer and float literal procotols

Proposal: SE- 

Authors: David Hart 
Review Manager: TBD
Status: TBD
 
Introduction

We propose a pair of protocols extending ExpressibleByIntegerLiteral and 
ExpressibleByFloatLiteral to allow initializing conforming types with arbitrary 
precision integer and floating-point literals.

 
Motivation

The current protocols ExpressibleByIntegerLiteral and ExpressibleByFloatLiteral 
are simple and work well but don't support arbitrary precision literal values. 
Replacing those protocols is a non-goal as they provide a simple interface for 
work well for most cases. Therefore, to support initializing big integer and 
big float types with literal values, we need new protocols.

 
Proposed
 solution

We propose:

renaming FloatingPointSign into Sign,
introducing a ExpressibleByArbitraryPrecisionIntegerLiteral protocol that 
extends ExpressibleByIntegerLiteral and provides a new arbitrary precision 
initializer,
introducing a ExpressibleByArbitraryPrecisionFloatLiteral protocol that extends 
ExpressibleByFloatLiteral and provides a new arbitrary precision initializer.
Here is the corresponding code:

/// The sign of a number.
public enum Sign : Int {

/// The sign for a positive value.
case plus

/// The sign for a negative value.
case minus
}

/// A type that can be initialized with an arbitrary precision integer literal.
public protocol ExpressibleByArbitraryPrecisionIntegerLiteral:
ExpressibleByIntegerLiteral {

/// Creates an instance initialized with the sign and memory value of the
/// arbitrary precision integer literal.
///
/// Do not call this initializer directly. Instead, initialize a variable or
/// constant using an arbitrary precision integer literal. For example:
///
/// let x = 123_456_789_123_456_789_123_456_789
///
/// In this example, the assignment to the `x` constant calls this integer
/// literal initializer behind the scenes with `sign` as `.plus` and
/// `buffer` as the memory [0x00661EFD, 0xF2E3B19F7C045F15].
///
/// - Parameters:
/// sign: The sign of the integer value.
/// buffer: The memory value of the integer.
init(sign: Sign, buffer: UnsafeBufferPointer)
}

/// A type that can be initialized with an arbitrary precision float literal.
public protocol ExpressibleByArbitraryPrecisionFloatLiteral:
ExpressibleByFloatLiteral {

/// Creates an instance initialized with the sign, exponent and
/// significand of the arbitrary precision float literal.
///
/// Do not call this initializer directly. Instead, initialize a variable or
/// constant using an arbitrary precision integer literal. For example:
///
/// let x = 123_456_789_123_456.789_123_456_789
///
/// In this example, the assignment to the `x` constant calls this float
/// literal initializer behind the scenes with `sign` as `.plus`, `exponent`
/// as the memory [0x00661EFD, 0xF2E3B19F7C045F15] and `significand`
/// with value [0x000C].
///
/// - Parameters:
/// sign: The sign of the integer value.
/// exponent: The memory value of the exponent.
/// significand: The memory value of the significand.
init(
sign: Sign,
exponent: UnsafeBufferPointer,
significand: UnsafeBufferPointer)
}



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

Re: [swift-evolution] Remove prefixes from all Apple frameworks

[Louis D'hauwe via swift-evolution]

Loud and clear! :-)
I am, however, very interested in the thoughts of the Swift evolution community 
for this idea.

– Louis D'hauwe

> On 30 Mar 2017, at 23:28, Joe Groff  wrote:
> 
>> 
>> On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution 
>>  wrote:
>> 
>> Apple frameworks contain prefixes, carried over from Objective-C.
>> These exist to prevent class and method name collisions.
>> 
>> Mattt Thompson has a great article about this, containing the following 
>> brilliant excerpt:
>> "Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
>> global implications, the language’s lack of identifier containers remains a 
>> source of prodigious quantities of caremad for armchair language critics." 
>> (http://nshipster.com/namespacing/)
>> 
>> Since Swift can handle with these naming conflicts, wouldn't it make sense 
>> to drop all framework prefixes in a Swift environment?
>> 
>> A classic example is UIKit, where all classes are prefixed with "UI". 
>> Code example:
>> 
>>import UIKit
>> 
>>class FooViewController: UIViewController {
>>  
>>}
>> 
>> Dropping the prefix would simply lead to the following:
>> 
>>import UIKit
>> 
>>class FooViewController: ViewController {
>>  
>>}
>> 
>> Since conflicts need to be handled by specifying the module name, the 
>> following could be used if "ViewController" was also used by either some, 
>> other than UIKit, imported framework or by a user defined class:
>> 
>>import UIKit
>> 
>>class FooViewController: UIKit.ViewController {
>>  
>>}
>> 
>> "UIKit.ViewController" is of course quite longer than the current 
>> "UIViewController".
>> An improvement could be to allow frameworks to specify an abbreviated form.
>> UIKit could define "UI" as its abbreviation, making the following code valid:
>> 
>>import UI
>> 
>>class FooViewController: UI.ViewController {
>>  
>>}
>> 
>> This all seems to me like a natural continuation of SE-0086.
>> I do realise this would be a major change, breaking pretty much every Swift 
>> iOS, macOS, tvOS and watchOS project.
>> But in the long term, I think it's worth it.
> 
> The teams at Apple own how their APIs get reflected in Swift. This is outside 
> the scope of swift-evolution.
> 
> -Joe

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Ben Cohen via swift-evolution]

> On Mar 30, 2017, at 2:03 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> So, running with the parallel, why not add a conditional conformance: "Slice: 
> Unicode where Base: Unicode”?
> 

Primarily because this would rule out giving substrings the “small string 
optimization" where we pack the characters into the struct directly when 
they’ll fit.

(or rather, given substrings will be 2-3 words, the not-even-that-small string 
optimization)


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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Ben Cohen via swift-evolution]

Hi Brent,

Thanks for the notes. Replies inline.

> On Mar 30, 2017, at 2:48 AM, Brent Royal-Gordon  
> wrote:
> 
>> On Mar 29, 2017, at 5:32 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hi Swift Evolution,
>> 
>> Below is a pitch for the first part of the String revision. This covers a 
>> number of changes that would allow the basic internals to be overhauled.
>> 
>> Online version here: 
>> https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md
> 
> Really great stuff, guys. Thanks for your work on this!
> 
>> In order to be able to write extensions accross both String and Substring, a 
>> new Unicode protocol to which the two types will conform will be introduced. 
>> For the purposes of this proposal, Unicode will be defined as a protocol to 
>> be used whenver you would previously extend String. It should be possible to 
>> substitute extension Unicode { ... } in Swift 4 wherever extension String { 
>> ... } was written in Swift 3, with one exception: any passing of self into 
>> an API that takes a concrete String will need to be rewritten as 
>> String(self). If Self is a String then this should effectively optimize to a 
>> no-op, whereas if Self is a Substring then this will force a copy, helping 
>> to avoid the “memory leak” problems described above.
> 
> I continue to feel that `Unicode` is the wrong name for this protocol, 
> essentially because it sounds like a protocol for, say, a version of Unicode 
> or some kind of encoding machinery instead of a Unicode string. I won't 
> rehash that argument since I made it already in the manifesto thread, but I 
> would like to make a couple new suggestions in this area.
> 
> Later on, you note that it would be nice to namespace many of these types:
> 
>> Several of the types related to String, such as the encodings, would ideally 
>> reside inside a namespace rather than live at the top level of the standard 
>> library. The best namespace for this is probably Unicode, but this is also 
>> the name of the protocol. At some point if we gain the ability to nest enums 
>> and types inside protocols, they should be moved there. Putting them inside 
>> String or some other enum namespace is probably not worthwhile in the 
>> mean-time.
> 
> Perhaps we should use an empty enum to create a `Unicode` namespace and then 
> nest the protocol within it via typealias. If we do that, we can consider 
> names like `Unicode.Collection` or even `Unicode.String` which would shadow 
> existing types if they were top-level.
> 

We’re a bit on the fence about whether Unicode or StringProtocol is the better 
name.

The big win for Unicode is it is short. We want to encourage people to write 
their extensions on this protocol. We want people who previously extended 
String to feel very comfortable extending Unicode. It also helps emphasis how 
important the Unicode-ness of Swift.String is. I like the idea of 
Unicode.Collection, but it is a little intimidating and making it even a tiny 
bit intimidating is worrying to me from an adoption perspective. 


> If not, then given this:
> 
>> The exact nature of the protocol – such as which methods should be protocol 
>> requirements vs which can be implemented as protocol extensions, are 
>> considered implementation details and so not covered in this proposal.
> 
> We may simply want to wait to choose a name. As the protocol develops, we may 
> discover a theme in its requirements which would suggest a good name. For 
> instance, we may realize that the core of what the protocol abstracts is 
> grouping code units into characters, which might suggest a name like 
> `Characters`, or `Unicode.Characters`, or `CharacterCollection`, or 
> what-have-you.
> 
> (By the way, I hope that the eventual protocol requirements will be put 
> through the review process, if only as an amendment, once they're determined.)
> 

Definitely. We just want to minimize churn on the group to keep the discussion 
followable on the broader principles for as many as possible. Once it’s firmed 
up and we’ve had implementation/useability/performance feedback, we’ll be back.

>> Unicode will conform to BidirectionalCollection. RangeReplaceableCollection 
>> conformance will be added directly onto the String and Substring types, as 
>> it is possible future Unicode-conforming types might not be 
>> range-replaceable (e.g. an immutable type that wraps a const char *).
> 
> I'm a little worried about this because it seems to imply that the protocol 
> cannot include any mutation operations that aren't in 
> `RangeReplaceableCollection`. For instance, it won't be possible to include 
> an in-place `applyTransform` method in the protocol. Do you anticipate that 
> being an issue? Might it be a good idea to define a parallel `Mutable` or 
> `RangeReplaceable` protocol?
> 

You can always assign to self. Then provide more efficient 

Re: [swift-evolution] Remove prefixes from all Apple frameworks

[Joe Groff via swift-evolution]

> On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution 
>  wrote:
> 
> Apple frameworks contain prefixes, carried over from Objective-C.
> These exist to prevent class and method name collisions.
> 
> Mattt Thompson has a great article about this, containing the following 
> brilliant excerpt:
> "Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
> global implications, the language’s lack of identifier containers remains a 
> source of prodigious quantities of caremad for armchair language critics." 
> (http://nshipster.com/namespacing/)
> 
> Since Swift can handle with these naming conflicts, wouldn't it make sense to 
> drop all framework prefixes in a Swift environment?
> 
> A classic example is UIKit, where all classes are prefixed with "UI". 
> Code example:
> 
> import UIKit
> 
> class FooViewController: UIViewController {
>   
> }
> 
> Dropping the prefix would simply lead to the following:
> 
> import UIKit
> 
> class FooViewController: ViewController {
>   
> }
> 
> Since conflicts need to be handled by specifying the module name, the 
> following could be used if "ViewController" was also used by either some, 
> other than UIKit, imported framework or by a user defined class:
> 
> import UIKit
> 
> class FooViewController: UIKit.ViewController {
>   
> }
> 
> "UIKit.ViewController" is of course quite longer than the current 
> "UIViewController".
> An improvement could be to allow frameworks to specify an abbreviated form.
> UIKit could define "UI" as its abbreviation, making the following code valid:
> 
> import UI
> 
> class FooViewController: UI.ViewController {
>   
> }
> 
> This all seems to me like a natural continuation of SE-0086.
> I do realise this would be a major change, breaking pretty much every Swift 
> iOS, macOS, tvOS and watchOS project.
> But in the long term, I think it's worth it.

The teams at Apple own how their APIs get reflected in Swift. This is outside 
the scope of swift-evolution.

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

Re: [swift-evolution] Remove prefixes from all Apple frameworks

[Adrian Zubarev via swift-evolution]

By an alias what I really meant was some kind of a macro like NS_SWIFT_NAME for 
types and the module name.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:19:51, Louis D'hauwe (louisdha...@silverfox.be) schrieb:

Aliases would be one step towards my vision, but long term I'd like to see a 
class like "UIViewController" to be imported as "ViewController".

On 30 Mar 2017, at 23:17, Adrian Zubarev  
wrote:

Typo: I actually meant type- and module-alias.




-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:16:14, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Something like a type- and type-alias when importing from Obj-C to Swift?

That would be reasonable, I’d guess.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdha...@silverfox.be) schrieb:

I disagree, my proposal is not to rename Apple frameworks. 
It is to improve the importing of Objective-C designed frameworks to remove the 
unnecessary prefixes.

– Louis D'hauwe

On 30 Mar 2017, at 23:07, Adrian Zubarev  
wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug 
report for the Apple frameworks, but I doubt something this huge will make it 
through.




-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution 
(swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following 
brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
global implications, the language’s lack of identifier containers remains a 
source of prodigious quantities of caremad for armchair language critics." 
(http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to 
drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI". 
Code example:

    import UIKit

    class FooViewController: UIViewController {

    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {

    }

Since conflicts need to be handled by specifying the module name, the following 
could be used if "ViewController" was also used by either some, other than 
UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {

    }

"UIKit.ViewController" is of course quite longer than the current 
"UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {

    }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift 
iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

___
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] Remove prefixes from all Apple frameworks

[Louis D'hauwe via swift-evolution]

Aliases would be one step towards my vision, but long term I'd like to see a 
class like "UIViewController" to be imported as "ViewController".

> On 30 Mar 2017, at 23:17, Adrian Zubarev  
> wrote:
> 
> Typo: I actually meant type- and module-alias.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 30. März 2017 um 23:16:14, Adrian Zubarev (adrian.zuba...@devandartist.com 
> ) schrieb:
> 
>> Something like a type- and type-alias when importing from Obj-C to Swift?
>> 
>> That would be reasonable, I’d guess.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdha...@silverfox.be 
>> ) schrieb:
>> 
>>> I disagree, my proposal is not to rename Apple frameworks. 
>>> It is to improve the importing of Objective-C designed frameworks to remove 
>>> the unnecessary prefixes.
>>> 
>>> – Louis D'hauwe
>>> 
 On 30 Mar 2017, at 23:07, Adrian Zubarev > wrote:
 
 The issue is, this has nothing to do with swift evolution. You could file 
 a bug report for the Apple frameworks, but I doubt something this huge 
 will make it through.
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> Apple frameworks contain prefixes, carried over from Objective-C.
> These exist to prevent class and method name collisions.
> 
> Mattt Thompson has a great article about this, containing the following 
> brilliant excerpt:
> "Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk 
> with global implications, the language’s lack of identifier containers 
> remains a source of prodigious quantities of caremad for armchair 
> language critics." (http://nshipster.com/namespacing/ 
> )
> 
> Since Swift can handle with these naming conflicts, wouldn't it make 
> sense to drop all framework prefixes in a Swift environment?
> 
> A classic example is UIKit, where all classes are prefixed with "UI". 
> Code example:
> 
> import UIKit
> 
> class FooViewController: UIViewController {
> 
> }
> 
> Dropping the prefix would simply lead to the following:
> 
> import UIKit
> 
> class FooViewController: ViewController {
> 
> }
> 
> Since conflicts need to be handled by specifying the module name, the 
> following could be used if "ViewController" was also used by either some, 
> other than UIKit, imported framework or by a user defined class:
> 
> import UIKit
> 
> class FooViewController: UIKit.ViewController {
> 
> }
> 
> "UIKit.ViewController" is of course quite longer than the current 
> "UIViewController".
> An improvement could be to allow frameworks to specify an abbreviated 
> form.
> UIKit could define "UI" as its abbreviation, making the following code 
> valid:
> 
> import UI
> 
> class FooViewController: UI.ViewController {
> 
> }
> 
> This all seems to me like a natural continuation of SE-0086 
> .
> I do realise this would be a major change, breaking pretty much every 
> Swift iOS, macOS, tvOS and watchOS project.
> But in the long term, I think it's worth it.
> 
> – Louis D'hauwe
> 
> ___
> 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] Remove prefixes from all Apple frameworks

[Adrian Zubarev via swift-evolution]

Typo: I actually meant type- and module-alias.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:16:14, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Something like a type- and type-alias when importing from Obj-C to Swift?

That would be reasonable, I’d guess.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdha...@silverfox.be) schrieb:

I disagree, my proposal is not to rename Apple frameworks. 
It is to improve the importing of Objective-C designed frameworks to remove the 
unnecessary prefixes.

– Louis D'hauwe

On 30 Mar 2017, at 23:07, Adrian Zubarev  
wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug 
report for the Apple frameworks, but I doubt something this huge will make it 
through.




-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution 
(swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following 
brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
global implications, the language’s lack of identifier containers remains a 
source of prodigious quantities of caremad for armchair language critics." 
(http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to 
drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI". 
Code example:

    import UIKit

    class FooViewController: UIViewController {

    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {

    }

Since conflicts need to be handled by specifying the module name, the following 
could be used if "ViewController" was also used by either some, other than 
UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {

    }

"UIKit.ViewController" is of course quite longer than the current 
"UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {

    }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift 
iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

___
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] Remove prefixes from all Apple frameworks

[Adrian Zubarev via swift-evolution]

Something like a type- and type-alias when importing from Obj-C to Swift?

That would be reasonable, I’d guess.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdha...@silverfox.be) schrieb:

I disagree, my proposal is not to rename Apple frameworks. 
It is to improve the importing of Objective-C designed frameworks to remove the 
unnecessary prefixes.

– Louis D'hauwe

On 30 Mar 2017, at 23:07, Adrian Zubarev  
wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug 
report for the Apple frameworks, but I doubt something this huge will make it 
through.




-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution 
(swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following 
brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
global implications, the language’s lack of identifier containers remains a 
source of prodigious quantities of caremad for armchair language critics." 
(http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to 
drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI". 
Code example:

    import UIKit

    class FooViewController: UIViewController {

    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {

    }

Since conflicts need to be handled by specifying the module name, the following 
could be used if "ViewController" was also used by either some, other than 
UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {

    }

"UIKit.ViewController" is of course quite longer than the current 
"UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {

    }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift 
iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

___
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] Remove prefixes from all Apple frameworks

[Louis D'hauwe via swift-evolution]

I disagree, my proposal is not to rename Apple frameworks. 
It is to improve the importing of Objective-C designed frameworks to remove the 
unnecessary prefixes.

– Louis D'hauwe

> On 30 Mar 2017, at 23:07, Adrian Zubarev  
> wrote:
> 
> The issue is, this has nothing to do with swift evolution. You could file a 
> bug report for the Apple frameworks, but I doubt something this huge will 
> make it through.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Apple frameworks contain prefixes, carried over from Objective-C.
>> These exist to prevent class and method name collisions.
>> 
>> Mattt Thompson has a great article about this, containing the following 
>> brilliant excerpt:
>> "Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
>> global implications, the language’s lack of identifier containers remains a 
>> source of prodigious quantities of caremad for armchair language critics." 
>> (http://nshipster.com/namespacing/ )
>> 
>> Since Swift can handle with these naming conflicts, wouldn't it make sense 
>> to drop all framework prefixes in a Swift environment?
>> 
>> A classic example is UIKit, where all classes are prefixed with "UI". 
>> Code example:
>> 
>> import UIKit
>> 
>> class FooViewController: UIViewController {
>> 
>> }
>> 
>> Dropping the prefix would simply lead to the following:
>> 
>> import UIKit
>> 
>> class FooViewController: ViewController {
>> 
>> }
>> 
>> Since conflicts need to be handled by specifying the module name, the 
>> following could be used if "ViewController" was also used by either some, 
>> other than UIKit, imported framework or by a user defined class:
>> 
>> import UIKit
>> 
>> class FooViewController: UIKit.ViewController {
>> 
>> }
>> 
>> "UIKit.ViewController" is of course quite longer than the current 
>> "UIViewController".
>> An improvement could be to allow frameworks to specify an abbreviated form.
>> UIKit could define "UI" as its abbreviation, making the following code valid:
>> 
>> import UI
>> 
>> class FooViewController: UI.ViewController {
>> 
>> }
>> 
>> This all seems to me like a natural continuation of SE-0086 
>> .
>> I do realise this would be a major change, breaking pretty much every Swift 
>> iOS, macOS, tvOS and watchOS project.
>> But in the long term, I think it's worth it.
>> 
>> – Louis D'hauwe
>> 
>> ___
>> 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] Remove prefixes from all Apple frameworks

[Karl Wagner via swift-evolution]

Oh yeah; and they might want to reserve unprefixed names for native Swift 
interfaces, similar to what happened to Foundation.

Maybe they already did. We’ll have to wait until WWDC for the next major 
version of the SDKs.

- Karl

> On 30 Mar 2017, at 23:07, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> The issue is, this has nothing to do with swift evolution. You could file a 
> bug report for the Apple frameworks, but I doubt something this huge will 
> make it through.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Apple frameworks contain prefixes, carried over from Objective-C.
>> These exist to prevent class and method name collisions.
>> 
>> Mattt Thompson has a great article about this, containing the following 
>> brilliant excerpt:
>> "Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
>> global implications, the language’s lack of identifier containers remains a 
>> source of prodigious quantities of caremad for armchair language critics." 
>> (http://nshipster.com/namespacing/ )
>> 
>> Since Swift can handle with these naming conflicts, wouldn't it make sense 
>> to drop all framework prefixes in a Swift environment?
>> 
>> A classic example is UIKit, where all classes are prefixed with "UI". 
>> Code example:
>> 
>> import UIKit
>> 
>> class FooViewController: UIViewController {
>> 
>> }
>> 
>> Dropping the prefix would simply lead to the following:
>> 
>> import UIKit
>> 
>> class FooViewController: ViewController {
>> 
>> }
>> 
>> Since conflicts need to be handled by specifying the module name, the 
>> following could be used if "ViewController" was also used by either some, 
>> other than UIKit, imported framework or by a user defined class:
>> 
>> import UIKit
>> 
>> class FooViewController: UIKit.ViewController {
>> 
>> }
>> 
>> "UIKit.ViewController" is of course quite longer than the current 
>> "UIViewController".
>> An improvement could be to allow frameworks to specify an abbreviated form.
>> UIKit could define "UI" as its abbreviation, making the following code valid:
>> 
>> import UI
>> 
>> class FooViewController: UI.ViewController {
>> 
>> }
>> 
>> This all seems to me like a natural continuation of SE-0086 
>> .
>> I do realise this would be a major change, breaking pretty much every Swift 
>> iOS, macOS, tvOS and watchOS project.
>> But in the long term, I think it's worth it.
>> 
>> – Louis D'hauwe
>> 
>> ___
>> 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] Remove prefixes from all Apple frameworks

[Adrian Zubarev via swift-evolution]

The issue is, this has nothing to do with swift evolution. You could file a bug 
report for the Apple frameworks, but I doubt something this huge will make it 
through.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution 
(swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following 
brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
global implications, the language’s lack of identifier containers remains a 
source of prodigious quantities of caremad for armchair language critics." 
(http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to 
drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI". 
Code example:

    import UIKit

    class FooViewController: UIViewController {

    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {

    }

Since conflicts need to be handled by specifying the module name, the following 
could be used if "ViewController" was also used by either some, other than 
UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {

    }

"UIKit.ViewController" is of course quite longer than the current 
"UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {

    }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift 
iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

___
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] Remove prefixes from all Apple frameworks

[Karl Wagner via swift-evolution]

+ Int.max

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

[swift-evolution] Remove prefixes from all Apple frameworks

[Louis D'hauwe via swift-evolution]

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following 
brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with 
global implications, the language’s lack of identifier containers remains a 
source of prodigious quantities of caremad for armchair language critics." 
(http://nshipster.com/namespacing/ )

Since Swift can handle with these naming conflicts, wouldn't it make sense to 
drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI". 
Code example:

import UIKit

class FooViewController: UIViewController {

}

Dropping the prefix would simply lead to the following:

import UIKit

class FooViewController: ViewController {

}

Since conflicts need to be handled by specifying the module name, the following 
could be used if "ViewController" was also used by either some, other than 
UIKit, imported framework or by a user defined class:

import UIKit

class FooViewController: UIKit.ViewController {

}

"UIKit.ViewController" is of course quite longer than the current 
"UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

import UI

class FooViewController: UI.ViewController {

}

This all seems to me like a natural continuation of SE-0086 
.
I do realise this would be a major change, breaking pretty much every Swift 
iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Karl Wagner via swift-evolution]

> On 30 Mar 2017, at 21:39, Robert Bennett via swift-evolution 
>  wrote:
> 
> Adrian,
> 
> I think there are a few competing claims here.
> 
> 1) Substring is a term of art used universally throughout computing, and 
> camel-casing it would run counter to that.
> 2) While subsequence is a word, its  precise mathematical meaning differs 
> from what it means in Swift. In Swift a SubSequence contains consecutive 
> elements of a sequence, whereas in math a subsequence may contain any subset 
> of the elements, ordered correctly. Hence Subsequence would be technically 
> incorrect (not a big issue IMO).
> 3) We want Sub[sS]tring and Sub[sS]equence to have the same capitalization.
> 
> I'd prefer ignoring 2 and satisfying 1 and 3, since there's no reason Swift's 
> names must exactly coincide with mathematical objects with the same name (for 
> instance, mathematical sets may contain anything at all, including 
> themselves). In addition, the prefix "Sub" does not usually (ever?) produce a 
> Sequence with wholly different mechanics, as do "Enumeration", "Zip2", etc. 
> -- the Subsequence really belongs to the owning Sequence. So my vote is for 
> Substring and Subsequence.
> 
> As for why not StringSlice... Substring is certainly a more familiar word. 
> That said, StringSlice would make it clearer that the slice is a view into a 
> String and is meant for temporary use only, which Substring might not convey. 
> If we choose StringSlice, I see no reason to change SubSequence to 
> Subsequence.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

+ 1 to StringSlice. In fact, I’m not sure if we even need Substring/StringSlice 
at all. We already have a Slice type.

The proposal mentions the parallel to ArraySlice, but ArraySlice is set to go: 
https://bugs.swift.org/browse/SR-3631

So, running with the parallel, why not add a conditional conformance: "Slice: 
Unicode where Base: Unicode”?

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Karl Wagner via swift-evolution]

> In order to be able to write extensions accross both String and Substring, a 
> new Unicode protocol to which the two types will conform will be introduced. 
> For the purposes of this proposal, Unicode will be defined as a protocol to 
> be used whenver you would previously extend String. It should be possible to 
> substitute extension Unicode { ... } in Swift 4 wherever extension String { 
> ... } was written in Swift 3, with one exception: any passing of self into an 
> API that takes a concrete String will need to be rewritten as String(self). 
> If Self is a String then this should effectively optimize to a no-op, whereas 
> if Self is a Substring then this will force a copy, helping to avoid the 
> “memory leak” problems described above.

Did you consider an AnyUnicode wrapper? Then we could have a 
typealias called “AnyString”.

Also, regarding naming: “Unicode” is great if this was a namespace, and this 
proposal is a great example of why protocol nesting is badly needed in Swift 
code which defines (not even very complex) protocols. However, absent protocol 
nesting, I think “UnicodeEncoded” is better. It doesn’t roll off the tongue as 
nicely, perhaps, but it also doesn’t look as weird when written in code.

> The exact nature of the protocol – such as which methods should be protocol 
> requirements vs which can be implemented as protocol extensions, are 
> considered implementation details and so not covered in this proposal.
> 
I’d hope they do get a proposal at some stage, though. There are cases where 
I’d like to be able to write my own “Unicode” type and take advantage of 
generic (and existential when we can) text processing.

For example, maybe the thing I want to present as a single block of text is 
actually pieced together from multiple discontiguous regions of a buffer (i.e. 
the “buffer-gap” approach for faster random insertions/deletions, if I expect 
my code to be doing lots of that).

You could imagine that if something like CoreText (can’t speak for them, of 
course) were being rewritten in Swift, it would be able to compute layouts and 
render glyphs from any provider of unicode data and not just String or 
Substring. I mean, that’s my dream, anyway. It would mean you could go directly 
from a buffer-gap String to a rendered bitmap suitable for UI.

> Unicode will conform to BidirectionalCollection. RangeReplaceableCollection 
> conformance will be added directly onto the String and Substring types, as it 
> is possible future Unicode-conforming types might not be range-replaceable 
> (e.g. an immutable type that wraps a const char *).
> 
+1. Keep the protocol focussed.

> The standard library currently lacks a Latin1 codec, so a enum Latin1: 
> UnicodeEncoding type will be added.
> 
I feel this is a call for better naming somewhere.

>   init(
> cString nulTerminatedCodeUnits: UnsafePointer,
> encoding: Encoding)

So will this replace the stuff which Foundation puts in to String, which also 
decodes a C string in to Swift string?

Foundation includes more encodings (and also nests an “Encoding” enum in String 
itself, which makes things even more confusing), but totally ignores standard 
library decodes in favour of CF ones.

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Nevin Brackett-Rozinsky via swift-evolution]

On Thu, Mar 30, 2017 at 3:39 PM, Robert Bennett via swift-evolution <
swift-evolution@swift.org> wrote:
>
>
> (for instance, mathematical sets may contain anything at all, including
> themselves)


Well actually they can’t ,
for…reasons  :-)

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

Re: [swift-evolution] [Pitch] Collection Type Element Property Observers

[Joshua Alvarado via swift-evolution]

I believe this will this impact performance on collections if you have to
do a computation on every item.

Also what about appending another collection to an existing collection?
Will there be a willAdd(newValue: Collection)?
Or will the willAdd(element: Element) be called multiple times?

I think think the gain of functionality isn't there for the addition of
this functionality to be added. There are other ways to implement what you
are desiring to do without adding it to Swift language.

On Thu, Mar 30, 2017 at 12:37 PM, Sean Alling via swift-evolution <
swift-evolution@swift.org> wrote:

> *PROPOSAL:*
>
> I propose the addition of the following new property observers applicable
> to all Collection types (Dictionary, Set, and Array):
>
> – *willAdd(newValue) { … }*
> – *didAdd(newValue) { … }*
>
> – *willRemove(oldValue) { … }*
> – *didRemove(oldValue) { … }*
>
> where, `newValue` and `oldValue` are *immutable*.
>
> This would allow one to perform additional work or observer logic to
> values added and removed from collections.  This model is consistent with
> Swift syntax and may perhaps minimize the use of NSNotifications in some
> situations.
>
> Currently, in order to perform this functionality some filtering and
> comparison logic would have to be performed from within a `willSet { … }`
> and `didSet { …}` call.  This change would not only ease that burden but
> promote a more visible and explicit expression that can further improve
> readability and traceability of functionality.
>
>
> *EXAMPLE USAGE:*
>
> var list = [objects]() {
> willAdd(newValue) {
> …
> }
> didAdd(newValue) {
> …
> }
> }
>
> var list = [key : object]() {
> willRemove(oldValue) {
> …
> }
> didRemove(oldValue) {
> …
> }
> }
>
>
> -
> Sean Alling
> alli...@icloud.com
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Joshua Alvarado
alvaradojosh...@gmail.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Dominik Pich via swift-evolution]

> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes

> Does this proposal fit well with the feel and direction of Swift?
Yes

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
None .. but I know I like type safety

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Karl Wagner via swift-evolution]

> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes

> Does this proposal fit well with the feel and direction of Swift?
Yes

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Lots of languages have key-paths, but usually they are strings. This adds some 
type-safety, so that’s nice.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading. I also have a couple of questions:

1) Can we get keypaths from protocol existentials?

protocol MyProto {
var something: Int { get }
}
struct MyThing: MyProto { /* … */ }

let myProtoSomethingKeypath = #keypath(MyProto, .something)
let value: Int = MyThing()[keypath: myProtoSomethingKeypath]  // seems 
reasonable, right?

2) What about if it has associated types?

let secondElement = #keypath(Collection, .subscript[1])  // if 
Collection.Iterator.Element had constraints, could we dig in to the instance?

let _: Int = [1,2,3][keypath: secondElement]
let _: String = [“a”, “b”, “c”][keypath: secondElement]


But I’d still +1 the proposal even if was limited to concrete types.

Also, that brings me to 2 related comments regarding the evolution of the 
feature:

1) It would be nice to allow keypaths of constrained protocol existentials

let secondElementFirstCharacter = #keypath(Collection where 
Iterator.Element == String, .subscript[0].characters.first)

2) It would be nice to be able to get keypaths to members which we don’t know 
exist. Members and protocol conformances may be retroactively added by 
3rd-party code.

And that’s all.

- Karl

> On 30 Mar 2017, at 18:25, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" 
> begins now and runs through April 5, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> 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] String revision proposal #1

[Ben Cohen via swift-evolution]

> On Mar 30, 2017, at 11:20 AM, Brent Royal-Gordon  
> wrote:
> 
> (That's why there's no adjective form of "string", which makes naming the 
> protocol difficult.)

We-eelll, there is “Stringy”….

As tempting as it is to call the protocol this, it’s probably not a good idea.

(then again, if we called it Text instead of String, we could then call the 
subsequence Subtext…)


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

[swift-evolution] [Pitch] String revision proposal #1

[Robert Bennett via swift-evolution]

Adrian,

I think there are a few competing claims here.

1) Substring is a term of art used universally throughout computing, and 
camel-casing it would run counter to that.
2) While subsequence is a word, its  precise mathematical meaning differs from 
what it means in Swift. In Swift a SubSequence contains consecutive elements of 
a sequence, whereas in math a subsequence may contain any subset of the 
elements, ordered correctly. Hence Subsequence would be technically incorrect 
(not a big issue IMO).
3) We want Sub[sS]tring and Sub[sS]equence to have the same capitalization.

I'd prefer ignoring 2 and satisfying 1 and 3, since there's no reason Swift's 
names must exactly coincide with mathematical objects with the same name (for 
instance, mathematical sets may contain anything at all, including themselves). 
In addition, the prefix "Sub" does not usually (ever?) produce a Sequence with 
wholly different mechanics, as do "Enumeration", "Zip2", etc. -- the 
Subsequence really belongs to the owning Sequence. So my vote is for Substring 
and Subsequence.

As for why not StringSlice... Substring is certainly a more familiar word. That 
said, StringSlice would make it clearer that the slice is a view into a String 
and is meant for temporary use only, which Substring might not convey. If we 
choose StringSlice, I see no reason to change SubSequence to Subsequence.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] String revision proposal #1

[Ben Cohen via swift-evolution]

> On Mar 30, 2017, at 8:59 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> We cannot rename SubSequence to Subsequence, because that would be odd 
> compared to all other types containing Sequence.
> 
> 
There is a difference between subsequence, which is one word, and the others, 
which are noun phrases (i.e. “any sequence”, “lazy sequence”). The issue is 
whether it’s "sub-sequence" (capitalization reasonable) or subsequence (no 
reason for caps).


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

Re: [swift-evolution] [Pitch] Collection Type Element Property Observers

[John McCall via swift-evolution]

> On Mar 30, 2017, at 3:16 PM, Sean Alling  wrote:
> John,
> 
> Sure, that is the pattern most commonly adopted for these cases but it does 
> in fact create a considerable amount of boilerplate code.  My hope was to 
> reduce the amount of boilerplate and the burden to create such a common 
> pattern of functionality.
> 
> I do understand that the implementation would be complex.  I am imagining 
> that these observers would get magically called when someone adds or removes 
> the collection.  The wrinkle I think you’re referring to is the fact that 
> there are a variety of ways in which a collection can be 'added to' and 
> 'removed from’.  Is that the complexity you are referring to?

Yes.  For example, you could pass the collection as an inout argument to a 
function that does who-knows-what to it.

John.

> 
> Sean
> 
> 
> 
>> On Mar 30, 2017, at 2:58 PM, John McCall > > wrote:
>> 
>>> On Mar 30, 2017, at 2:37 PM, Sean Alling via swift-evolution 
>>> > wrote:
>>> PROPOSAL:
>>> 
>>> I propose the addition of the following new property observers applicable 
>>> to all Collection types (Dictionary, Set, and Array):
>>> 
>>> – willAdd(newValue) { … }
>>> – didAdd(newValue) { … }
>>> 
>>> – willRemove(oldValue) { … }
>>> – didRemove(oldValue) { … }
>>> 
>>> where, `newValue` and `oldValue` are immutable.
>>> 
>>> This would allow one to perform additional work or observer logic to values 
>>> added and removed from collections.  This model is consistent with Swift 
>>> syntax and may perhaps minimize the use of NSNotifications in some 
>>> situations.
>>> 
>>> Currently, in order to perform this functionality some filtering and 
>>> comparison logic would have to be performed from within a `willSet { … }` 
>>> and `didSet { …}` call.  This change would not only ease that burden but 
>>> promote a more visible and explicit expression that can further improve 
>>> readability and traceability of functionality.
>> 
>> Figuring out that an arbitrary change to a collection is an "add" or a 
>> "remove" of a specific element is, well, let's just say it's complex.  If 
>> you're imagining that these observers would just get magically called when 
>> someone called the add or remove method on the property, that's not really 
>> how these language features work together.
>> 
>> The property behaviors proposal would let you do things like automatically 
>> computing differences and calling these observers, if you really want to do 
>> that.  But the better solution is almost certainly to (1) make the 
>> collection property private(set) and (2) just declare addToList and 
>> removeFromList methods that do whatever you would want to do in the observer.
>> 
>> John.
>> 
>>> 
>>> 
>>> EXAMPLE USAGE:
>>> 
>>> var list = [objects]() {
>>> willAdd(newValue) {
>>> … 
>>> }
>>> didAdd(newValue) {
>>> …
>>> }
>>> }
>>> 
>>> var list = [key : object]() {
>>> willRemove(oldValue) {
>>> …
>>> }
>>> didRemove(oldValue) {
>>> …
>>> }
>>> }
>>> 
>>> 
>>> -
>>> Sean Alling
>>> alli...@icloud.com 
>>> ___
>>> 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] Collection Type Element Property Observers

[Sean Alling via swift-evolution]

John,

Sure, that is the pattern most commonly adopted for these cases but it does in 
fact create a considerable amount of boilerplate code.  My hope was to reduce 
the amount of boilerplate and the burden to create such a common pattern of 
functionality.

I do understand that the implementation would be complex.  I am imagining that 
these observers would get magically called when someone adds or removes the 
collection.  The wrinkle I think you’re referring to is the fact that there are 
a variety of ways in which a collection can be 'added to' and 'removed from’.  
Is that the complexity you are referring to?

Sean



> On Mar 30, 2017, at 2:58 PM, John McCall  wrote:
> 
>> On Mar 30, 2017, at 2:37 PM, Sean Alling via swift-evolution 
>> > wrote:
>> PROPOSAL:
>> 
>> I propose the addition of the following new property observers applicable to 
>> all Collection types (Dictionary, Set, and Array):
>> 
>> – willAdd(newValue) { … }
>> – didAdd(newValue) { … }
>> 
>> – willRemove(oldValue) { … }
>> – didRemove(oldValue) { … }
>> 
>> where, `newValue` and `oldValue` are immutable.
>> 
>> This would allow one to perform additional work or observer logic to values 
>> added and removed from collections.  This model is consistent with Swift 
>> syntax and may perhaps minimize the use of NSNotifications in some 
>> situations.
>> 
>> Currently, in order to perform this functionality some filtering and 
>> comparison logic would have to be performed from within a `willSet { … }` 
>> and `didSet { …}` call.  This change would not only ease that burden but 
>> promote a more visible and explicit expression that can further improve 
>> readability and traceability of functionality.
> 
> Figuring out that an arbitrary change to a collection is an "add" or a 
> "remove" of a specific element is, well, let's just say it's complex.  If 
> you're imagining that these observers would just get magically called when 
> someone called the add or remove method on the property, that's not really 
> how these language features work together.
> 
> The property behaviors proposal would let you do things like automatically 
> computing differences and calling these observers, if you really want to do 
> that.  But the better solution is almost certainly to (1) make the collection 
> property private(set) and (2) just declare addToList and removeFromList 
> methods that do whatever you would want to do in the observer.
> 
> John.
> 
>> 
>> 
>> EXAMPLE USAGE:
>> 
>> var list = [objects]() {
>>  willAdd(newValue) {
>>  … 
>>  }
>>  didAdd(newValue) {
>>  …
>>  }
>> }
>> 
>> var list = [key : object]() {
>>  willRemove(oldValue) {
>>  …
>>  }
>>  didRemove(oldValue) {
>>  …
>>  }
>> }
>> 
>> 
>> -
>> Sean Alling
>> alli...@icloud.com 
>> ___
>> 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] Collection Type Element Property Observers

[John McCall via swift-evolution]

> On Mar 30, 2017, at 2:37 PM, Sean Alling via swift-evolution 
>  wrote:
> PROPOSAL:
> 
> I propose the addition of the following new property observers applicable to 
> all Collection types (Dictionary, Set, and Array):
> 
> – willAdd(newValue) { … }
> – didAdd(newValue) { … }
> 
> – willRemove(oldValue) { … }
> – didRemove(oldValue) { … }
> 
> where, `newValue` and `oldValue` are immutable.
> 
> This would allow one to perform additional work or observer logic to values 
> added and removed from collections.  This model is consistent with Swift 
> syntax and may perhaps minimize the use of NSNotifications in some situations.
> 
> Currently, in order to perform this functionality some filtering and 
> comparison logic would have to be performed from within a `willSet { … }` and 
> `didSet { …}` call.  This change would not only ease that burden but promote 
> a more visible and explicit expression that can further improve readability 
> and traceability of functionality.

Figuring out that an arbitrary change to a collection is an "add" or a "remove" 
of a specific element is, well, let's just say it's complex.  If you're 
imagining that these observers would just get magically called when someone 
called the add or remove method on the property, that's not really how these 
language features work together.

The property behaviors proposal would let you do things like automatically 
computing differences and calling these observers, if you really want to do 
that.  But the better solution is almost certainly to (1) make the collection 
property private(set) and (2) just declare addToList and removeFromList methods 
that do whatever you would want to do in the observer.

John.

> 
> 
> EXAMPLE USAGE:
> 
> var list = [objects]() {
>   willAdd(newValue) {
>   … 
>   }
>   didAdd(newValue) {
>   …
>   }
> }
> 
> var list = [key : object]() {
>   willRemove(oldValue) {
>   …
>   }
>   didRemove(oldValue) {
>   …
>   }
> }
> 
> 
> -
> Sean Alling
> alli...@icloud.com 
> ___
> 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] [Pitch] Collection Type Element Property Observers

[Sean Alling via swift-evolution]

PROPOSAL:

I propose the addition of the following new property observers applicable to 
all Collection types (Dictionary, Set, and Array):

– willAdd(newValue) { … }
– didAdd(newValue) { … }

– willRemove(oldValue) { … }
– didRemove(oldValue) { … }

where, `newValue` and `oldValue` are immutable.

This would allow one to perform additional work or observer logic to values 
added and removed from collections.  This model is consistent with Swift syntax 
and may perhaps minimize the use of NSNotifications in some situations.

Currently, in order to perform this functionality some filtering and comparison 
logic would have to be performed from within a `willSet { … }` and `didSet { 
…}` call.  This change would not only ease that burden but promote a more 
visible and explicit expression that can further improve readability and 
traceability of functionality.


EXAMPLE USAGE:

var list = [objects]() {
willAdd(newValue) {
… 
}
didAdd(newValue) {
…
}
}

var list = [key : object]() {
willRemove(oldValue) {
…
}
didRemove(oldValue) {
…
}
}


-
Sean Alling
alli...@icloud.com ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] String revision proposal #1

[Brent Royal-Gordon via swift-evolution]

> On Mar 30, 2017, at 8:38 AM, Ben Cohen via swift-evolution 
>  wrote:
> 
> It should definitely be Substring. My rule of thumb: if you might hyphenate 
> it, you can capitalize it.

I was going to make the same argument, but you beat me to it. 

"String" and "Substring" are both terms of art. (That's why there's no 
adjective form of "string", which makes naming the protocol difficult.) And 
they're probably the most widely-used terms of art in programming. "Substring" 
is inconsistent with other parts of the language, but for a good reason. 

Keep it. 

-- 
Brent Royal-Gordon
Sent from my iPhone

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

Re: [swift-evolution] (Pitch) Conformance Regions

[Félix Cloutier via swift-evolution]

What will you do if you want to privately adopt two protocols that require 
identical members?

Also, you write that you want to be able to write members into extensions but 
you can't. Have you considered pushing to make it possible? 

> Le 30 mars 2017 à 10:07, Ross O'Brien via swift-evolution 
>  a écrit :
> 
> This idea was had during the SE-0159 Review regarding removing fileprivate  
> and I'm creating a new discussion thread for its consideration. It's neither 
> in favour of nor against keeping fileprivate, but is intended to address an 
> idiom which has led to some resentment against fileprivate.
> 
> Copy-pasting from my original post on this:
> 
> When we declare a type, we declare properties and functions which that type 
> has.
> When we extend a type, we add functions to the type. (I'm including computed 
> properties in this.)
> It has become an idiom of Swift to declare an extension to a type for each 
> protocol we want it to conform to, for reasons of code organisation and 
> readability. This can be true even if conformance to the protocol was a 
> primary intent of creating the type in the first place.
> 
> The intent of the scoped access level (one use of the current private 
> keyword) is to allow programmers to create properties and functions which are 
> limited to the scope of their declaration. A protocol conformance can be 
> written, with the aid of helper functions, in the confidence that the helper 
> functions are not visible outside the extension, minimising their impact on 
> other components of the module.
> However, some protocol conformances require the type to have a specific 
> property, which the extension cannot facilitate. Some protocol conformances 
> don't require a property, but it would be really useful to have one, and 
> again an extension can't facilitate.
> 
> Example: we want to be able to write this, but we can't:
> 
> private protocol Bar
> {
>   var integer : Int { get }
>   func increment()
> }
> 
> struct Foo
> {
> }
> 
> extension Foo : Bar
> {
>   var integer : Int
> 
>   private var counter : Int
>   func increment()
>   {
> counter += 1
>   }
> }
> 
> This leads to a workaround: that properties are added to the original type, 
> and declared as fileprivate. They're not intended to be visible to any scope 
> other than the conforming extension - not even, really, to the type's 
> original scope.
> 
> Continuing the example: we've compromised and written this:
> 
> struct Foo
> {
>   fileprivate var integer : Int
>   fileprivate var counter : Int
> }
> 
> extension Foo : Bar
> {
>   func increment()
>   {
> counter += 1
>   }
> }
> 
> This is not a fault of fileprivate (though it's a clunky name), or private. 
> Renaming these levels does not solve the problem. Removing private, such that 
> everything becomes fileprivate, does not solve the problem. The problem is in 
> the extension system.
> 
> Proposal:
> Suppose we approached extensions differently.
> 
> Suppose we created a 'conformance region' inside a type declaration - a scope 
> nested within the type declaration scope - and that this conformance region 
> had its own access level. It's inside the type declaration, not separate from 
> it like an extension, so we can declare properties inside it. But literally 
> the only properties and functions declared inside the region but visible 
> anywhere outside of it, would be properties and functions declared in the 
> named protocol being conformed to.
> 
> So, visually it might look like this:
> 
> struct Foo
> {
>   conformance Bar // or conformance Foo : Bar, but since the region is inside 
> Foo that's redundant
>   {
> var integer : Int // visible because Foo : Bar, at Bar's access level
> 
> var counter : Int = 0 // only visible inside the conformance scope, 
> because not declared in Bar
> 
> func increment() // visible because Foo : Bar, at Bar's access level
> {
>   counter += 1
> }
>   }
> }
> 
> I've introduced a new keyword for this example, conformance, though it may be 
> clear enough to keep using extension. As the extension is inside the type 
> there's no need to redeclare the type being extended. From this example, Foo 
> conforms to Bar, in the same file; it's just been written inside Foo's type 
> declaration, and indented one level, instead of after it.
> 
> Aspects worth considering (some already pointed out by others):
> The original idea for this is that the conformance region exists only to 
> allow the type to conform to a protocol (though possibly more than one), and 
> that only properties and functions declared in those protocols would be 
> accessible outside of the region, at whatever access level the protocol(s) 
> originally declared.
> Existing access terms (internal, fileprivate, etc.) could be used to increase 
> the visibility (to a maximum of the visibility of the declared type, e.g. a 
> public property in a conformance region of an internal type 

[swift-evolution] (Pitch) Conformance Regions

[Ross O'Brien via swift-evolution]

This idea was had during the SE-0159 Review regarding removing fileprivate
and I'm creating a new discussion thread for its consideration. It's
neither in favour of nor against keeping fileprivate, but is intended to
address an idiom which has led to some resentment against fileprivate.

Copy-pasting from my original post on this:

When we declare a type, we declare properties and functions which that type
has.
When we extend a type, we add functions to the type. (I'm including
computed properties in this.)
It has become an idiom of Swift to declare an extension to a type for each
protocol we want it to conform to, for reasons of code organisation and
readability. This can be true even if conformance to the protocol was a
primary intent of creating the type in the first place.

The intent of the scoped access level (one use of the current private keyword)
is to allow programmers to create properties and functions which are
limited to the scope of their declaration. A protocol conformance can be
written, with the aid of helper functions, in the confidence that the
helper functions are not visible outside the extension, minimising their
impact on other components of the module.
However, some protocol conformances require the type to have a specific
property, which the extension cannot facilitate. Some protocol conformances
don't require a property, but it would be really useful to have one, and
again an extension can't facilitate.

Example: we want to be able to write this, but we can't:

private protocol Bar

{

  var integer : Int { get }

  func increment()

}


struct Foo

{

}


extension Foo : Bar

{

  var integer : Int


  private var counter : Int

  func increment()

  {

  counter += 1

  }

}

This leads to a workaround: that properties are added to the original type,
and declared as fileprivate. They're not intended to be visible to any
scope other than the conforming extension - not even, really, to the type's
original scope.

Continuing the example: we've compromised and written this:


struct Foo

{

  fileprivate var integer : Int

  fileprivate var counter : Int

}


extension Foo : Bar

{

  func increment()

  {

  counter += 1

  }

}

This is not a fault of fileprivate (though it's a clunky name), or private.
Renaming these levels does not solve the problem. Removing private, such
that everything becomes fileprivate, does not solve the problem. The
problem is in the extension system.

Proposal:
Suppose we approached extensions differently.

Suppose we created a 'conformance region' inside a type declaration - a
scope nested within the type declaration scope - and that this conformance
region had its own access level. It's inside the type declaration, not
separate from it like an extension, so we can declare properties inside it.
But literally the only properties and functions declared inside the region
but visible anywhere outside of it, would be properties and functions
declared in the named protocol being conformed to.

So, visually it might look like this:


struct Foo

{

  conformance Bar // or conformance Foo : Bar, but since the region is
inside Foo that's redundant

  {

  var integer : Int // visible because Foo : Bar, at Bar's access level


  var counter : Int = 0 // only visible inside the conformance scope,
because not declared in Bar


  func increment() // visible because Foo : Bar, at Bar's access level

  {

  counter += 1

  }

  }

}

I've introduced a new keyword for this example, conformance, though it may
be clear enough to keep using extension. As the extension is inside the
type there's no need to redeclare the type being extended. From this
example, Foo conforms to Bar, in the same file; it's just been written
inside Foo's type declaration, and indented one level, instead of after it.

Aspects worth considering (some already pointed out by others):
The original idea for this is that the conformance region exists only to
allow the type to conform to a protocol (though possibly more than one),
and that only properties and functions declared in those protocols would be
accessible outside of the region, at whatever access level the protocol(s)
originally declared.
Existing access terms (internal, fileprivate, etc.) could be used to
increase the visibility (to a maximum of the visibility of the declared
type, e.g. a public property in a conformance region of an internal type
conforming to a fileprivate protocol would be an internally visible
property). This would introduce no new keywords.
However, as this defines a new default level within a region of the
language, an explicit keyword might be preferred and a default level of
internal might be more intuitive.

This idea presently assumes that conformance regions do not nest. An inner
nested type would be able to declare conformance regions in its
declaration, and cannot be extended inside another conformance region of
the outer type. However, there might be different thoughts on this?

We might consider conformance 

Re: [swift-evolution] [Pitch] String revision proposal #1

[Karim Nassar via swift-evolution]

> Message: 12
> Date: Thu, 30 Mar 2017 12:23:13 +0200
> From: Adrian Zubarev 
> To: Ben Cohen 
> Cc: swift-evolution@swift.org
> Subject: Re: [swift-evolution] [Pitch] String revision proposal #1
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
> 
> I haven’t followed the topic and while reading the proposal I found it a 
> little confusing that we have inconsistent type names. I’m not a native 
> English speaker so that’s might be the main case for my confusion here, so 
> I’d appreciate for any clarification. ;-)
> 
> SubSequence vs. Substring and not SubString.
> 
> The word substring is an English word, but so is subsequence (I double 
> checked here).
> 
> So where exactly is the issue here? Is it SubSequence which is written in 
> camel case or is it Substring which is not?
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail


I’d also be curious if StringSlice was considered, since we have already the 
well-established and seemingly-parallel ArraySlice.

—Karim

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Félix Cloutier via swift-evolution]

I don't have much non-nitpick issues that I greatly care about; I'm in favor of 
this.

My only request: it's currently painful to create a String from a fixed-size C 
array. For instance, if I have a pointer to a `struct foo { char name[16]; }` 
in Swift where the last character doesn't have to be a NUL, it's hard to create 
a String from it. Real-world examples of this are Mach-O LC_SEGMENT and 
LC_SEGMENT_64 commands.

The generally-accepted wisdom  is 
that you take a pointer to the CChar tuple that represents the fixed-size 
array, but this still requires the string to be NUL-terminated. What do we 
think of an additional init(cString:) overload that takes an 
UnsafeBufferPointer and reads up to the first NUL or the end of the buffer, 
whichever comes first?

> Le 30 mars 2017 à 02:48, Brent Royal-Gordon via swift-evolution 
>  a écrit :
> 
>> On Mar 29, 2017, at 5:32 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hi Swift Evolution,
>> 
>> Below is a pitch for the first part of the String revision. This covers a 
>> number of changes that would allow the basic internals to be overhauled.
>> 
>> Online version here: 
>> https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md
> 
> Really great stuff, guys. Thanks for your work on this!
> 
>> In order to be able to write extensions accross both String and Substring, a 
>> new Unicode protocol to which the two types will conform will be introduced. 
>> For the purposes of this proposal, Unicode will be defined as a protocol to 
>> be used whenver you would previously extend String. It should be possible to 
>> substitute extension Unicode { ... } in Swift 4 wherever extension String { 
>> ... } was written in Swift 3, with one exception: any passing of self into 
>> an API that takes a concrete String will need to be rewritten as 
>> String(self). If Self is a String then this should effectively optimize to a 
>> no-op, whereas if Self is a Substring then this will force a copy, helping 
>> to avoid the “memory leak” problems described above.
> 
> I continue to feel that `Unicode` is the wrong name for this protocol, 
> essentially because it sounds like a protocol for, say, a version of Unicode 
> or some kind of encoding machinery instead of a Unicode string. I won't 
> rehash that argument since I made it already in the manifesto thread, but I 
> would like to make a couple new suggestions in this area.
> 
> Later on, you note that it would be nice to namespace many of these types:
> 
>> Several of the types related to String, such as the encodings, would ideally 
>> reside inside a namespace rather than live at the top level of the standard 
>> library. The best namespace for this is probably Unicode, but this is also 
>> the name of the protocol. At some point if we gain the ability to nest enums 
>> and types inside protocols, they should be moved there. Putting them inside 
>> String or some other enum namespace is probably not worthwhile in the 
>> mean-time.
> 
> Perhaps we should use an empty enum to create a `Unicode` namespace and then 
> nest the protocol within it via typealias. If we do that, we can consider 
> names like `Unicode.Collection` or even `Unicode.String` which would shadow 
> existing types if they were top-level.
> 
> If not, then given this:
> 
>> The exact nature of the protocol – such as which methods should be protocol 
>> requirements vs which can be implemented as protocol extensions, are 
>> considered implementation details and so not covered in this proposal.
> 
> We may simply want to wait to choose a name. As the protocol develops, we may 
> discover a theme in its requirements which would suggest a good name. For 
> instance, we may realize that the core of what the protocol abstracts is 
> grouping code units into characters, which might suggest a name like 
> `Characters`, or `Unicode.Characters`, or `CharacterCollection`, or 
> what-have-you.
> 
> (By the way, I hope that the eventual protocol requirements will be put 
> through the review process, if only as an amendment, once they're determined.)
> 
>> Unicode will conform to BidirectionalCollection. RangeReplaceableCollection 
>> conformance will be added directly onto the String and Substring types, as 
>> it is possible future Unicode-conforming types might not be 
>> range-replaceable (e.g. an immutable type that wraps a const char *).
> 
> I'm a little worried about this because it seems to imply that the protocol 
> cannot include any mutation operations that aren't in 
> `RangeReplaceableCollection`. For instance, it won't be possible to include 
> an in-place `applyTransform` method in the protocol. Do you anticipate that 
> being an issue? Might it be a good idea to define a parallel `Mutable` or 
> `RangeReplaceable` protocol?
> 
>> The C string interop methods will be 

[swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" 
begins now and runs through April 5, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
Reply text
Other replies
 What 
goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug

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

Re: [swift-evolution] Smart KeyPaths

[Joe Groff via swift-evolution]

> On Mar 30, 2017, at 6:54 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution 
>>  wrote:
>>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution 
>>>  wrote:
>>> I'm not a fan of the new syntax for creating key paths. To me, it feels 
>>> like they've been demoted to second class citizens of the language simply 
>>> because of how more verbose it now is. The new syntax is also too 
>>> confusingly similar to string key paths: I had to look closely at the code 
>>> to see the difference. Is there no symbol we can use to make it ambiguous? 
>>> Ideas:
>>> 
>>> Person::friend.lastName
>>> Person/friend.lastName
>>> Person#friend.lastName
>>> 
>>> I'm a fan of the first one as it has similarities to names pacing in C++.
>> 
>> I'm a big fan of the last one.  I argued for it earlier as the best syntax 
>> to use if we deviated from the initial proposal.  I like it for several 
>> reasons:
>> 
>> - # suggests compiler magic is at work which is the case here.
>> - #friend.lastName works nicely as a shorthand in contexts expecting a key 
>> path with a fixed Root
>> - # would work for unbound methods solving the no arguments case.  IMO all 
>> unbound members should be accessed using the same syntax.
>> - # enables the possibility of mixing property access and method calls in 
>> the path as a future enhancement
>> 
>> The arguments supporting this approach are pretty strong to me.  I agree 
>> with David that the #keyPath syntax makes it feel more like a second class 
>> citizen, not just because of the verbosity but also because it is directly 
>> borrowed from an Objective-C interop feature.  This is a very powerful 
>> feature that deserves to be a first class syntactic citizen every bit as 
>> much as unbound methods do.
> 
> Personally I'd prefer the use of a leading dollar sign for this, for example:
> 
>   $Person.friend.lastName
> 
> I find a symbol midway through the path a bit strange, plus the leading 
> dollar sign already implies compiler magic in the same way as anonymous 
> parameters in closures. In fact you can think of anonymous parameters as a 
> kind of special key-path of sorts, and there should be no ambiguity.
> 
> I prefer this to the hash symbol for compiler directives, since those feel 
> more like things that are done once during compilation, rather than something 
> you actually use at run-time, so I like the distinction of another symbol for 
> that.

$ is reserved for the debugger. We don't really have many free symbols to burn, 
and it would be unwise to burn one on a new feature before having evidence that 
it deserves it.

-Joe 

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Adrian Zubarev via swift-evolution]

If I had to choose as a not native English speaker I’d go for SubString just 
for the camel case consistency across all other types.

We cannot rename SubSequence to Subsequence, because that would be odd compared 
to all other types containing Sequence.

AnySequence
LazyPrefixWhileSequence
LazySequence
EnumeratedSequence
etc.
This won’t break anything or create any other inconsistency.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 17:51:09, Joshua Alvarado via swift-evolution 
(swift-evolution@swift.org) schrieb:

...my vote would be to lowercase Subsequence. We can typealias SubSequence = 
Subsequence to aid migration
 
+1 didn't think that was an option. A good solution would be to have them 
either camel case (SubString, SubSequence) or just capitalized (Substring, 
Substring) either would be nice as long as they were matching.

On Thu, Mar 30, 2017 at 9:38 AM, Ben Cohen via swift-evolution 
 wrote:

On Mar 29, 2017, at 6:59 PM, Xiaodi Wu  wrote:

This looks great. The restored conformances to *Collection will be huge.

Is this to be the first of several or the only major part of the manifesto to 
be delivered in Swift 4?


First of several. This lays the ground work for the changes to the underlying 
implementation. Other changes will mostly be additive on top.

Nits on naming: are we calling it Substring or SubString (à la SubSequence)?

This is venturing into subjective territory, so these are just my feelings 
rather than something definitive (Dave may differ) but:

It should definitely be Substring. My rule of thumb: if you might hyphenate it, 
you can capitalize it. I don’t think anyone spells it "sub-string". OTOH one 
might write "sub-sequence". Generally hyphens disappear in english as things 
come into common usage i.e. it used to be e-mail but now it’s mostly just 
email.  Substring is enough of a term of art in programming that this has 
happened. Admittedly, Subsequence is a term of art too – unfortunately one that 
has a different meaning to ours ("a sequence that can be derived from another 
sequence by deleting some elements without changing the order of the remaining 
elements" e.g.  is a Subsequence of  – see 
https://en.wikipedia.org/wiki/Subsequence). Even worse, the mathematical term 
for what we are calling a subsequence is a Substring!

If we were change anything, my vote would be to lowercase Subsequence. We can 
typealias SubSequence = Subsequence to aid migration, with a slow burn on 
deprecating it since it’ll be quite a footling deprecation. I don’t know if 
it’s worth it though – the main use of “SubSequence” is currently in those 
pesky where clauses you have to put on all your Collection extensions if you 
want to use slicing, and many of these will be eliminated once we have the 
ability to put where clauses on associated types.

and shouldn't it be UnicodeParsedResult rather than UnicodeParseResult?


I think Parse. As in, this is the result of a parse, not these are the parsed 
results (though it does contain parsed results in some cases, but not all).


On Wed, Mar 29, 2017 at 19:32 Ben Cohen via swift-evolution 
 wrote:
Hi Swift Evolution,

Below is a pitch for the first part of the String revision. This covers a 
number of changes that would allow the basic internals to be overhauled.

Online version here: 
https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md


String Revision: Collection Conformance, C Interop, Transcoding

Proposal: SE-0161
Authors: Ben Cohen, Dave Abrahams
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal is to implement a subset of the changes from the Swift 4 String 
Manifesto.

Specifically:

Make String conform to BidirectionalCollection
Make String conform to RangeReplaceableCollection
Create a Substring type for String.SubSequence
Create a Unicode protocol to allow for generic operations over both types.
Consolidate on a concise set of C interop methods.
Revise the transcoding infrastructure.
Other existing aspects of String remain unchanged for the purposes of this 
proposal.

Motivation

This proposal follows up on a number of recommendations found in the manifesto:

Collection conformance was dropped from String in Swift 2. After reevaluation, 
the feeling is that the minor semantic discrepancies (mainly with 
RangeReplaceableCollection) are outweighed by the significant benefits of 
restoring these conformances. For more detail on the reasoning, see here

While it is not a collection, the Swift 3 string does have slicing operations. 
String is currently serving as its own subsequence, allowing substrings to 
share storage with their “owner”. This can lead to memory leaks when small 
substrings of larger strings are stored long-term (see here for more detail on 
this problem). Introducing a separate type of Substring to serve as 

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

> On Mar 30, 2017, at 9:54 AM, Haravikk via swift-evolution 
>  wrote:
> 
> Personally I'd prefer the use of a leading dollar sign for this, for example:
> 
>   $Person.friend.lastName

That looks clean.  I don't think it could get confused with referencing named 
tuples because the type begins with uppercase.


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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Joshua Alvarado via swift-evolution]

>
> ...my vote would be to lowercase Subsequence. We can typealias
> SubSequence = Subsequence to aid migration


+1 didn't think that was an option. A good solution would be to have them
either camel case (SubString, SubSequence) or just capitalized (Substring,
Substring) either would be nice as long as they were matching.

On Thu, Mar 30, 2017 at 9:38 AM, Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 29, 2017, at 6:59 PM, Xiaodi Wu  wrote:
>
> This looks great. The restored conformances to *Collection will be huge.
>
> Is this to be the first of several or the only major part of the manifesto
> to be delivered in Swift 4?
>
>
> First of several. This lays the ground work for the changes to the
> underlying implementation. Other changes will mostly be additive on top.
>
> Nits on naming: are we calling it Substring or SubString (à la
> SubSequence)?
>
>
> This is venturing into subjective territory, so these are just my feelings
> rather than something definitive (Dave may differ) but:
>
> It should definitely be Substring. My rule of thumb: if you might
> hyphenate it, you can capitalize it. I don’t think anyone spells it
> "sub-string". OTOH one *might* write "sub-sequence". Generally hyphens
> disappear in english as things come into common usage i.e. it used to be
> e-mail but now it’s mostly just email.  Substring is enough of a term of
> art in programming that this has happened. Admittedly, Subsequence is a
> term of art too – unfortunately one that has a different meaning to ours
> ("a sequence that can be derived from another sequence by deleting some
> elements without changing the order of the remaining elements" e.g. 
> is a Subsequence of  – see https://en.wikipedia.org/
> wiki/Subsequence). Even worse, the mathematical term for what we are
> calling a subsequence is a Substring!
>
> If we were change anything, my vote would be to lowercase Subsequence. We
> can typealias SubSequence = Subsequence to aid migration, with a slow burn
> on deprecating it since it’ll be quite a footling deprecation. I don’t know
> if it’s worth it though – the main use of “SubSequence” is currently in
> those pesky where clauses you have to put on all your Collection extensions
> if you want to use slicing, and many of these will be eliminated once we
> have the ability to put where clauses on associated types.
>
> and shouldn't it be UnicodeParsedResult rather than UnicodeParseResult?
>
>
> I think Parse. As in, this is the result of a parse, not these are the
> parsed results (though it does contain parsed results in some cases, but
> not all).
>
>
> On Wed, Mar 29, 2017 at 19:32 Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Swift Evolution,
>
> Below is a pitch for the first part of the String revision. This covers a
> number of changes that would allow the basic internals to be overhauled.
>
> Online version here: https://github.com/airspeedswift/swift-evolution/
> blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-
> StringRevision1.md
>
>
> String Revision: Collection Conformance, C Interop, Transcoding
>
>- Proposal: SE-0161
>- Authors: Ben Cohen , Dave Abrahams
>
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> Introduction
>
> This proposal is to implement a subset of the changes from the Swift 4
> String Manifesto
> .
>
> Specifically:
>
>- Make String conform to BidirectionalCollection
>- Make String conform to RangeReplaceableCollection
>- Create a Substring type for String.SubSequence
>- Create a Unicode protocol to allow for generic operations over both
>types.
>- Consolidate on a concise set of C interop methods.
>- Revise the transcoding infrastructure.
>
> Other existing aspects of String remain unchanged for the purposes of
> this proposal.
> Motivation
>
> This proposal follows up on a number of recommendations found in the
> manifesto:
>
> Collection conformance was dropped from String in Swift 2. After
> reevaluation, the feeling is that the minor semantic discrepancies (mainly
> with RangeReplaceableCollection) are outweighed by the significant
> benefits of restoring these conformances. For more detail on the reasoning,
> see here
> 
>
> While it is not a collection, the Swift 3 string does have slicing
> operations. String is currently serving as its own subsequence, allowing
> substrings to share storage with their “owner”. This can lead to memory
> leaks when small substrings of larger strings are stored long-term (see
> here
> 
>  for
> more detail on this problem). Introducing a separate type of 

Re: [swift-evolution] [Pitch] String revision proposal #1

[Zach Waldowski via swift-evolution]

Loving it so far.



`encode` and `parseScalar[Forward|Backward]` feel asymmetric. What's
wrong with `decode[Forward|Backward]`?


`UnicodeParseResult` really feels like it could/should be
defined as `UnicodeEncoding.ParseResult` (or `DecodeResult`,
given the above). I can't remember if that generics limitation was
being lifted?


Best,

  Zachary Waldowski

  z...@waldowski.me





On Wed, Mar 29, 2017, at 08:32 PM, Ben Cohen via swift-evolution wrote:
> Hi Swift Evolution,

> 

> Below is a pitch for the first part of the String revision. This
> covers a number of changes that would allow the basic internals to be
> overhauled.
> 

> Online version here:
> https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md
> 

> 

> String Revision: Collection Conformance, C Interop, Transcoding


>  * Proposal: SE-0161
>  * Authors: Ben Cohen[1], Dave Abrahams[2]
>  * Review Manager: TBD
>  * Status: *Awaiting review*
> Introduction



> This proposal is to implement a subset of the changes from the Swift 4
> String Manifesto[3].
> Specifically:


>  * Make String conform to BidirectionalCollection
>  * Make String conform to RangeReplaceableCollection
>  * Create a Substring type for String.SubSequence
>  * Create a Unicode protocol to allow for generic operations over both
>types.
>  * Consolidate on a concise set of C interop methods.
>  * __Revise the transcoding infrastructure.
> Other existing aspects of String remain unchanged for the purposes of
> this proposal.
> Motivation



> This proposal follows up on a number of recommendations found in the
> manifesto:
> Collection conformance was dropped from String in Swift 2. After
> reevaluation, the feeling is that the minor semantic discrepancies
> (mainly with RangeReplaceableCollection) are outweighed by the
> significant benefits of restoring these conformances. For more detail
> on the reasoning, see here[4]
> While it is not a collection, the Swift 3 string does have slicing
> operations. String is currently serving as its own subsequence,
> allowing substrings to share storage with their “owner”. This can lead
> to memory leaks when small substrings of larger strings are stored long-
> term (see here[5] for more detail on this problem). Introducing a
> separate type of Substring to serve as String.Subsequence is
> recommended to resolve this issue, in a similar fashion to ArraySlice.
> As noted in the manifesto, support for interoperation with nul-
> terminated C strings in Swift 3 is scattered and incoherent, with 6
> ways to transform a C string into a String and four ways to do the
> inverse. These APIs should be replaced with a simpler set of methods
> on String.
> Proposed solution



> A new type, Substring, will be introduced. Similar to ArraySlice it
> will be documented as only for short- to medium-term storage:
>> *Important*



>> Long-term storage of Substring instances is discouraged. A substring
>> holds a reference to the entire storage of a larger string, not just
>> to the portion it presents, even after the original string’s lifetime
>> ends. Long-term storage of a substring may therefore prolong the
>> lifetime of elements that are no longer otherwise accessible, which
>> can appear to be memory leakage.
> Aside from minor differences, such as having a SubSequence of Self and
> a larger size to describe the range of the subsequence, Substring will
> be near-identical from a user perspective.
> In order to be able to write extensions accross both String and
> Substring, a new Unicode protocol to which the two types will conform
> will be introduced. For the purposes of this proposal, Unicode will be
> defined as a protocol to be used whenver you would previously extend
> String. It should be possible to substitute extension Unicode { ... }
> in Swift 4 wherever extension String { ... } was written in Swift 3,
> with one exception: any passing of self into an API that takes a
> concrete String will need to be rewritten as String(self). If Self is
> a String then this should effectively optimize to a no-op, whereas if
> Self is a Substring then this will force a copy, helping to avoid the
> “memory leak” problems described above.
> The exact nature of the protocol – such as which methods should be
> protocol requirements vs which can be implemented as protocol
> extensions, are considered implementation details and so not covered
> in this proposal.
> Unicode will conform to BidirectionalCollection.
> RangeReplaceableCollection conformance will be added directly onto the
> String and Substring types, as it is possible future Unicode-
> conforming types might not be range-replaceable (e.g. an immutable
> type that wraps a const char *).
> The C string interop methods will be updated to those described
> here[6]: a single withCString operation and two init(cString:)
> constructors, one for UTF8 and one for arbitrary encodings. The
> primary change is to 

Re: [swift-evolution] [Pitch] String revision proposal #1

[Ben Cohen via swift-evolution]

> On Mar 29, 2017, at 6:59 PM, Xiaodi Wu  wrote:
> 
> This looks great. The restored conformances to *Collection will be huge.
> 
> Is this to be the first of several or the only major part of the manifesto to 
> be delivered in Swift 4?
> 

First of several. This lays the ground work for the changes to the underlying 
implementation. Other changes will mostly be additive on top.

> Nits on naming: are we calling it Substring or SubString (à la SubSequence)?

This is venturing into subjective territory, so these are just my feelings 
rather than something definitive (Dave may differ) but:

It should definitely be Substring. My rule of thumb: if you might hyphenate it, 
you can capitalize it. I don’t think anyone spells it "sub-string". OTOH one 
might write "sub-sequence". Generally hyphens disappear in english as things 
come into common usage i.e. it used to be e-mail but now it’s mostly just 
email.  Substring is enough of a term of art in programming that this has 
happened. Admittedly, Subsequence is a term of art too – unfortunately one that 
has a different meaning to ours ("a sequence that can be derived from another 
sequence by deleting some elements without changing the order of the remaining 
elements" e.g.  is a Subsequence of  – see 
https://en.wikipedia.org/wiki/Subsequence 
). Even worse, the mathematical term 
for what we are calling a subsequence is a Substring!

If we were change anything, my vote would be to lowercase Subsequence. We can 
typealias SubSequence = Subsequence to aid migration, with a slow burn on 
deprecating it since it’ll be quite a footling deprecation. I don’t know if 
it’s worth it though – the main use of “SubSequence” is currently in those 
pesky where clauses you have to put on all your Collection extensions if you 
want to use slicing, and many of these will be eliminated once we have the 
ability to put where clauses on associated types.

> and shouldn't it be UnicodeParsedResult rather than UnicodeParseResult?
> 

I think Parse. As in, this is the result of a parse, not these are the parsed 
results (though it does contain parsed results in some cases, but not all).

> 
> On Wed, Mar 29, 2017 at 19:32 Ben Cohen via swift-evolution 
> > wrote:
> Hi Swift Evolution,
> 
> Below is a pitch for the first part of the String revision. This covers a 
> number of changes that would allow the basic internals to be overhauled.
> 
> Online version here: 
> https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md
>  
> 
> 
> 
> String Revision: Collection Conformance, C Interop, Transcoding
> 
> Proposal: SE-0161 <>
> Authors: Ben Cohen , Dave Abrahams 
> 
> Review Manager: TBD
> Status: Awaiting review
> Introduction
> 
> This proposal is to implement a subset of the changes from the Swift 4 String 
> Manifesto 
> .
> 
> Specifically:
> 
> Make String conform to BidirectionalCollection
> Make String conform to RangeReplaceableCollection
> Create a Substring type for String.SubSequence
> Create a Unicode protocol to allow for generic operations over both types.
> Consolidate on a concise set of C interop methods.
> Revise the transcoding infrastructure.
> Other existing aspects of String remain unchanged for the purposes of this 
> proposal.
> 
> Motivation
> 
> This proposal follows up on a number of recommendations found in the 
> manifesto:
> 
> Collection conformance was dropped from String in Swift 2. After 
> reevaluation, the feeling is that the minor semantic discrepancies (mainly 
> with RangeReplaceableCollection) are outweighed by the significant benefits 
> of restoring these conformances. For more detail on the reasoning, see here 
> 
> While it is not a collection, the Swift 3 string does have slicing 
> operations. String is currently serving as its own subsequence, allowing 
> substrings to share storage with their “owner”. This can lead to memory leaks 
> when small substrings of larger strings are stored long-term (see here 
> 
>  for more detail on this problem). Introducing a separate type of Substring 
> to serve as String.Subsequence is recommended to resolve this issue, in a 
> similar fashion to ArraySlice.
> 
> As noted in the manifesto, support for interoperation with nul-terminated C 
> strings in Swift 3 is scattered and incoherent, with 6 ways to transform a C 
> string into a 

Re: [swift-evolution] [Pitch] String revision proposal #1

[Joshua Alvarado via swift-evolution]

Restoring Collection conformance back to String is a big win for Swift!
This revision looks great but I agree with the naming I believe it should
be SubString not Substring. I think SubString looks odd written out over
Substring but it keeps the convention of SubSequence.

On Wed, Mar 29, 2017 at 7:59 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> This looks great. The restored conformances to *Collection will be huge.
>
> Is this to be the first of several or the only major part of the manifesto
> to be delivered in Swift 4?
>
> Nits on naming: are we calling it Substring or SubString (à la
> SubSequence)? and shouldn't it be UnicodeParsedResult rather than
> UnicodeParseResult?
>
>
> On Wed, Mar 29, 2017 at 19:32 Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Swift Evolution,
>
> Below is a pitch for the first part of the String revision. This covers a
> number of changes that would allow the basic internals to be overhauled.
>
> Online version here: https://github.com/airspeedswift/swift-evolution/
> blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-
> StringRevision1.md
>
>
> String Revision: Collection Conformance, C Interop, Transcoding
>
>- Proposal: SE-0161
>- Authors: Ben Cohen , Dave Abrahams
>
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> Introduction
>
> This proposal is to implement a subset of the changes from the Swift 4
> String Manifesto
> .
>
> Specifically:
>
>- Make String conform to BidirectionalCollection
>- Make String conform to RangeReplaceableCollection
>- Create a Substring type for String.SubSequence
>- Create a Unicode protocol to allow for generic operations over both
>types.
>- Consolidate on a concise set of C interop methods.
>- Revise the transcoding infrastructure.
>
> Other existing aspects of String remain unchanged for the purposes of
> this proposal.
> Motivation
>
> This proposal follows up on a number of recommendations found in the
> manifesto:
>
> Collection conformance was dropped from String in Swift 2. After
> reevaluation, the feeling is that the minor semantic discrepancies (mainly
> with RangeReplaceableCollection) are outweighed by the significant
> benefits of restoring these conformances. For more detail on the reasoning,
> see here
> 
>
> While it is not a collection, the Swift 3 string does have slicing
> operations. String is currently serving as its own subsequence, allowing
> substrings to share storage with their “owner”. This can lead to memory
> leaks when small substrings of larger strings are stored long-term (see
> here
> 
>  for
> more detail on this problem). Introducing a separate type of Substring to
> serve as String.Subsequence is recommended to resolve this issue, in a
> similar fashion to ArraySlice.
>
> As noted in the manifesto, support for interoperation with nul-terminated
> C strings in Swift 3 is scattered and incoherent, with 6 ways to transform
> a C string into a String and four ways to do the inverse. These APIs
> should be replaced with a simpler set of methods on String.
> Proposed solution
>
> A new type, Substring, will be introduced. Similar to ArraySlice it will
> be documented as only for short- to medium-term storage:
>
> *Important*
> Long-term storage of Substring instances is discouraged. A substring
> holds a reference to the entire storage of a larger string, not just to the
> portion it presents, even after the original string’s lifetime ends.
> Long-term storage of a substring may therefore prolong the lifetime of
> elements that are no longer otherwise accessible, which can appear to be
> memory leakage.
>
> Aside from minor differences, such as having a SubSequence of Self and a
> larger size to describe the range of the subsequence, Substring will be
> near-identical from a user perspective.
>
> In order to be able to write extensions accross both String and Substring,
> a new Unicode protocol to which the two types will conform will be
> introduced. For the purposes of this proposal, Unicode will be defined as
> a protocol to be used whenver you would previously extend String. It
> should be possible to substitute extension Unicode { ... } in Swift 4
> wherever extension String { ... } was written in Swift 3, with one
> exception: any passing of self into an API that takes a concrete String will
> need to be rewritten as String(self). If Self is a String then this
> should effectively optimize to a no-op, whereas if Self is a Substring then
> this will force a copy, helping to avoid the “memory leak” problems
> described above.
>
> The exact nature of the protocol 

Re: [swift-evolution] Smart KeyPaths

[Vladimir.S via swift-evolution]

On 30.03.2017 16:12, Matthew Johnson via swift-evolution wrote:



Sent from my iPad

On Mar 30, 2017, at 12:35 AM, David Hart via swift-evolution
> wrote:






Sent from my iPhone
On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution
> wrote:


Thanks for the feedback everyone!  We have pushed a changed a bit ago to
the proposal reflecting these desires.

https://github.com/apple/swift-evolution/pull/644/files

-Michael


I'm not a fan of the new syntax for creating key paths. To me, it feels
like they've been demoted to second class citizens of the language simply
because of how more verbose it now is. The new syntax is also too
confusingly similar to string key paths: I had to look closely at the
code to see the difference. Is there no symbol we can use to make it
ambiguous? Ideas:

Person::friend.lastName
Person/friend.lastName
Person#friend.lastName

I'm a fan of the first one as it has similarities to names pacing in C++.


I'm a big fan of the last one.  I argued for it earlier as the best syntax
to use if we deviated from the initial proposal.  I like it for several
reasons:

- # suggests compiler magic is at work which is the case here.
- #friend.lastName works nicely as a shorthand in contexts expecting a key
path with a fixed Root
- # would work for unbound methods solving the no arguments case.  IMO all
unbound members should be accessed using the same syntax.


Strong support. IMO proposal should be currently updated to unify the 
syntax of unbound methods access and key path access, IMO *this* should be 
one of the main targets of the proposal. I.e.


var method1 = MyType#foo() // unbound method
var method2 = MyType#foo(param:) // unbound method
var keypath = MyType#person.name // keypath

Personally I think the '@' could be used also as("type AT path"):

var method = MyType@foo() // unbound method
var keypath = myt...@person.name // keypath

But I agree that '#' is a strong marker that we are dealing with some 
compiler magic here.



- # enables the possibility of mixing property access and method calls in
the path as a future enhancement

The arguments supporting this approach are pretty strong to me.  I agree
with David that the #keyPath syntax makes it feel more like a second class
citizen, not just because of the verbosity but also because it is directly
borrowed from an Objective-C interop feature.  This is a very powerful
feature that deserves to be a first class syntactic citizen every bit as
much as unbound methods do.



David.


On Mar 29, 2017, at 2:49 PM, Douglas Gregor > wrote:



On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution
> wrote:

Hi friendly swift-evolution folks,

The Foundation and Swift team  would like for you to consider the
following proposal:



The Swift core team discussed this proposal draft and had a little bit
of pre-review feedback.


Access and Mutation Through KeyPaths

To get or set values for a given root and key path we effectively add
the following subscripts to all Swift types.

Swift
|extension Any { subscript(path: AnyKeyPath) -> Any? { get }
subscript(path: PartialKeyPath) -> Any { get }
subscript(path: KeyPath) -> Value {
get } subscript(path: WritableKeyPath)
-> Value { set, get } }|


Swift doesn’t currently have the ability to extend Any, so this is
(currently) pseudocode for compiler magic that one day we might be able
to place. Additionally, the “Root: Self” constraint isn’t something we
support in the generics system. A small note indicating that this is
pseudo-code meant to get the point across (rather than real code to
drop into the standard library/Foundation) would be appreciated.

More importantly, this adds an unlabeled subscript to every type, which
raises concerns about introducing ambiguities—even if not hard
ambiguities that prevent code from compiling (e.g., from a
Dictionary)---they can still show up in code completion,
diagnostics, etc.

The core team would prefer that this subscript distinguish itself more,
e.g., by labeling the first parameter “keyPath” (or some better name,
if there is one). Syntactically, that would look like:

person[keyPath: theKeyPathIHave]


Referencing Key Paths

Forming a |KeyPath| borrows from the same syntax used to reference
methods and initializers,|Type.instanceMethod| only now working for
properties and collections. Optionals are handled via
optional-chaining. Multiply dotted expressions are allowed as well,
and work just as if they were composed via the |appending| methods
on |KeyPath|.


The core team was concerned about the use of the Type.instanceProperty
syntax for a few reasons:

* It doesn’t work for forming keypaths to class/static properties (or
is ambiguous with the existing meaning(, so we 

Re: [swift-evolution] Smart KeyPaths

[Haravikk via swift-evolution]

> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution 
>  wrote:
>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution 
>> > wrote:
>> I'm not a fan of the new syntax for creating key paths. To me, it feels like 
>> they've been demoted to second class citizens of the language simply because 
>> of how more verbose it now is. The new syntax is also too confusingly 
>> similar to string key paths: I had to look closely at the code to see the 
>> difference. Is there no symbol we can use to make it ambiguous? Ideas:
>> 
>> Person::friend.lastName
>> Person/friend.lastName
>> Person#friend.lastName
>> 
>> I'm a fan of the first one as it has similarities to names pacing in C++.
> 
> I'm a big fan of the last one.  I argued for it earlier as the best syntax to 
> use if we deviated from the initial proposal.  I like it for several reasons:
> 
> - # suggests compiler magic is at work which is the case here.
> - #friend.lastName works nicely as a shorthand in contexts expecting a key 
> path with a fixed Root
> - # would work for unbound methods solving the no arguments case.  IMO all 
> unbound members should be accessed using the same syntax.
> - # enables the possibility of mixing property access and method calls in the 
> path as a future enhancement
> 
> The arguments supporting this approach are pretty strong to me.  I agree with 
> David that the #keyPath syntax makes it feel more like a second class 
> citizen, not just because of the verbosity but also because it is directly 
> borrowed from an Objective-C interop feature.  This is a very powerful 
> feature that deserves to be a first class syntactic citizen every bit as much 
> as unbound methods do.

Personally I'd prefer the use of a leading dollar sign for this, for example:

$Person.friend.lastName

I find a symbol midway through the path a bit strange, plus the leading dollar 
sign already implies compiler magic in the same way as anonymous parameters in 
closures. In fact you can think of anonymous parameters as a kind of special 
key-path of sorts, and there should be no ambiguity.

I prefer this to the hash symbol for compiler directives, since those feel more 
like things that are done once during compilation, rather than something you 
actually use at run-time, so I like the distinction of another symbol for that.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Nested extensions and stored properties

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Mar 30, 2017 at 1:16 PM, Vladimir.S via swift-evolution
 wrote:
> So, both top level extensions and nested would have only 'fileprivate',
> 'internal' or 'public'. 'scoped' is not allowed for them(if we accept the
> above suggestions):
>
> class MyType { // internal
>   public var a = 10 // internal(because of type's access level)
>   var b = 20 // internal
>   scoped var c = 30 // scoped for type and for nested extensions
>
>   // default and max level is fileprivate, bounded by type's access level
>   fileprivate extension MyProtoA {
> scoped var d = 10 // scoped for extension, inaccessible outside  of it
>
> var e = 20 // fileprivate
> internal var f = 20 // fileprivate
> public var g = 30 // fileprivate
>
> func foo() { print(c, i, m) } // can access c, i, m
>   }
>
>   // default and max level is internal, bounded by type's access level
>   extension MyProtoB {
> scoped var h = 40 // scoped for extension, inaccessible outside  of it
>
> var i = 50 // internal
> internal var j = 60 // internal
> public var k = 70 // public->internal(type's access level)
>   }
>
>   // default and max level is public, bounded by type's access level

I think this is internal even if declared public.

>   public extension MyProtoC {
> scoped var l = 80 // scoped for extension, inaccessible outside  of it
>
> var m = 90 // public -> internal(type's access level)
> internal var n = 100 // internal
> public var o = 110 // public->internal(type's access level)
>   }
> }
>
> Do you see any drawbacks in such design? (given that we disallow scoped
> access modifier at top level of file and for nested extensions in type)

To me it's very difficult to understand at first glance what's
happening in that code, or what is the intent for those modifiers. For
example, in my mind it takes way too much to compute the access level
for a variable inside a nested extension.

For me it's immensely useful that the compilers warns you when you
declare a subtype/property/method with an wider access modifier than
the current scope.

In general the whole proposal looks complicated, and for me it's hard
to imagine an use case for such needs.

It probably be because of my own limitations, but in my day to day and
when reviewing open source code, I crave for simpler access levels,
not for more granularity. The only friction that I see is having to
declare a method/property fileprivate instead of private because you
want to use from an extension in the same file.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 30, 2017, at 12:35 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution 
>  wrote:
> 
>> Thanks for the feedback everyone!  We have pushed a changed a bit ago to the 
>> proposal reflecting these desires.
>> 
>> https://github.com/apple/swift-evolution/pull/644/files
>> 
>> -Michael
> 
> I'm not a fan of the new syntax for creating key paths. To me, it feels like 
> they've been demoted to second class citizens of the language simply because 
> of how more verbose it now is. The new syntax is also too confusingly similar 
> to string key paths: I had to look closely at the code to see the difference. 
> Is there no symbol we can use to make it ambiguous? Ideas:
> 
> Person::friend.lastName
> Person/friend.lastName
> Person#friend.lastName
> 
> I'm a fan of the first one as it has similarities to names pacing in C++.

I'm a big fan of the last one.  I argued for it earlier as the best syntax to 
use if we deviated from the initial proposal.  I like it for several reasons:

- # suggests compiler magic is at work which is the case here.
- #friend.lastName works nicely as a shorthand in contexts expecting a key path 
with a fixed Root
- # would work for unbound methods solving the no arguments case.  IMO all 
unbound members should be accessed using the same syntax.
- # enables the possibility of mixing property access and method calls in the 
path as a future enhancement

The arguments supporting this approach are pretty strong to me.  I agree with 
David that the #keyPath syntax makes it feel more like a second class citizen, 
not just because of the verbosity but also because it is directly borrowed from 
an Objective-C interop feature.  This is a very powerful feature that deserves 
to be a first class syntactic citizen every bit as much as unbound methods do.

> 
> David.
> 
 On Mar 29, 2017, at 2:49 PM, Douglas Gregor  wrote:
 
 
 On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution 
  wrote:
 
 Hi friendly swift-evolution folks,
 
 The Foundation and Swift team  would like for you to consider the 
 following proposal:
>>> 
>>> 
>>> The Swift core team discussed this proposal draft and had a little bit of 
>>> pre-review feedback.
>>> 
 Access and Mutation Through KeyPaths
 To get or set values for a given root and key path we effectively add the 
 following subscripts to all Swift types. 
 
 Swift
 extension Any {
 subscript(path: AnyKeyPath) -> Any? { get }
 subscript(path: PartialKeyPath) -> Any { get }
 subscript(path: KeyPath) -> Value { 
 get }
 subscript(path: WritableKeyPath) -> 
 Value { set, get }
 }
>>> 
>>> Swift doesn’t currently have the ability to extend Any, so this is 
>>> (currently) pseudocode for compiler magic that one day we might be able to 
>>> place. Additionally, the “Root: Self” constraint isn’t something we support 
>>> in the generics system. A small note indicating that this is pseudo-code 
>>> meant to get the point across (rather than real code to drop into the 
>>> standard library/Foundation) would be appreciated.
>>> 
>>> More importantly, this adds an unlabeled subscript to every type, which 
>>> raises concerns about introducing ambiguities—even if not hard ambiguities 
>>> that prevent code from compiling (e.g., from a Dictionary>> …>)---they can still show up in code completion, diagnostics, etc.
>>> 
>>> The core team would prefer that this subscript distinguish itself more, 
>>> e.g., by labeling the first parameter “keyPath” (or some better name, if 
>>> there is one). Syntactically, that would look like:
>>> 
>>> person[keyPath: theKeyPathIHave]
>>> 
 Referencing Key Paths
 
 Forming a KeyPath borrows from the same syntax used to reference methods 
 and initializers,Type.instanceMethod only now working for properties and 
 collections. Optionals are handled via optional-chaining. Multiply dotted 
 expressions are allowed as well, and work just as if they were composed 
 via the appending methods on KeyPath.
 
>>> The core team was concerned about the use of the Type.instanceProperty 
>>> syntax for a few reasons:
>>> 
>>> * It doesn’t work for forming keypaths to class/static properties (or 
>>> is ambiguous with the existing meaning(, so we would need another syntax to 
>>> deal with that case
>>> * It’s quite subtle, even more so that the existing Type.instanceMethod 
>>> syntax for currying instance methods
>>> 
 There is no change or interaction with the #keyPath() syntax introduced in 
 Swift 3. 
 
>>> The core team felt that extending the #keyPath syntax was a better 
>>> syntactic direction to produce key-paths.
>>> 

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

> On Mar 29, 2017, at 10:21 PM, James Berry via swift-evolution 
>  wrote:
> 
> Or migrate swift 3 #keyPath to #objcKeyPath to preserve that legacy intent 
> while retaining #keyPath for our bright and unsullied future? ;)

I like this suggestion. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Nested extensions and stored properties

[Vladimir.S via swift-evolution]

I suggest to discuss the idea brought up by Ross O'Brien in "SE-0159: Fix 
Private Access Levels" thread about "'conformance region' inside a type 
declaration - a scope nested within the type declaration scope" in this 
separate thread. Initially Ross suggested the special 'conformance' 
keyword(you can check the thread or quoted text in this email), but it 
seems like it is more reasonable to reuse 'extension' keyword for the same 
purpose. Please find my last reply below the Xiaodi's reply, if you are 
interested in discussion.


I assume this is a purely additive feature and is not in current plans for 
Swift 4, but we could discuss if we want such feature in such 
implementation for future proposals.


I see such benefits of this idea:
* We leave current model of extensions "as is", no changes for extensions
declared outside of the type.
* IMO we need stored properties in extensions at least in the same file
with type declaration(as was shown by discussion in the list) - and the
proposed solution gives them to us
* IMO this solution is better than just allow stored properties in
extensions in the same file:
	* in the latter case extension has no access to 'scoped' members of type 
but this can be very useful to implement protocol conformance with help of 
internal(scoped) details, that should not be exposed to whole file level.

* with proposed solution it is clear that any member declared in
extension block is a native part of type. We can see all members in the 
same type definition.
	* proposed solution has a simple mental model - "all that is defined 
inside type declaration is naturally a part of that type, stored properties 
allowed only for nested extensions, 'scoped' access 'uses' same rules as 
usually".



On 28.03.2017 1:33, Xiaodi Wu wrote:

Note that allowing nested extensions will require breaking rules for access
modifiers on all extensions. This is because, during revisions for SE-0025,
the idea of aligning rules for extensions to rules for types was brought up
and rejected. Subsequent proposals to do so also failed at various stages.

The current rule for types is as follows: the visibility of the type is the
upper limit for visibility of its members. Members have an implicit access
level of internal but may state any other access level, even if higher than
the containing type, and the _effective_ access level will be restricted by
the containing type. For example: `internal struct S { public var i: Int }`
has a member that is _effectively_ internal.

The current rule for extensions is as follows: although extensions are a
scope for the purposes of "new private", they are not a first-class entity
and have no existence in the type system. As such, they cannot be the upper
limit for members. Instead, the access modifier for an extension is unique
in Swift: it is regarded as a "shorthand" for the default access modifier
for contained members and also the maximum permitted access level for those
members; for example, inside a "public extension" the members default to
public (not internal). Attempts to remove this behavior were fiercely
rejected by those who want to use the shorthand to have an extension full
of public members without restating "public".

If, however, it is a "private extension", then the default access modifier
for members in that extension is "fileprivate". This is correct *only* if
extensions can never be nested. There is no spelling for the maximum
possible visibility of a member inside a _nested_ private extension, and it
is not permitted to state an explicit access level greater than that of the
extension itself. If you want to support nested extensions, then this rule
cannot continue. However, previous attempts at harmonizing these rules were
not successful.


OK, I see your point, thank you for detailed description.

First, probably (as was discussed in this thread) we should disallow 
'scoped' access level(current 'private') at top level of file. This IMO 
will remove one of the big confusion point : 'scoped' will be allowed only 
inside a scope less than file.
So, in this case, you'll have no "private extension"(current 'private') - 
only "fileprivate extension" at top level.


(I'll use 'scoped' and 'fileprivate' below to be clear what I mean. 
Currently they are 'private' and 'fileprivate', and probably will be 
'scoped' and 'private')


Second - "There is no spelling for the maximum possible visibility of a 
member inside a _nested_ private extension".. I.e. member with even 
'public' access modifier in such extension will be effectively 'scoped' and 
so nothing can be used outside of the extension ? If I understood correctly 
- then it seems like we should just not allow 'scoped' for nested 
extensions as such extension just has no sense.


So, both top level extensions and nested would have only 'fileprivate', 
'internal' or 'public'. 'scoped' is not allowed for them(if we accept the 
above suggestions):


class MyType { // internal
  public var a = 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Vladimir.S via swift-evolution]

[offtopic]
Just wonder, if I missed the resolution for SE-0159? (although I even 
checked the list's archive). There was IMO a very low activity in the list 
in last couple of days, so I decided to ask if probably there was a problem 
with mailing server etc..

[/offtopic]

On 28.03.2017 17:36, Vladimir.S wrote:

On 28.03.2017 1:33, Xiaodi Wu wrote:

Note that allowing nested extensions will require breaking rules for access
modifiers on all extensions. This is because, during revisions for SE-0025,
the idea of aligning rules for extensions to rules for types was brought up
and rejected. Subsequent proposals to do so also failed at various stages.

The current rule for types is as follows: the visibility of the type is the
upper limit for visibility of its members. Members have an implicit access
level of internal but may state any other access level, even if higher than
the containing type, and the _effective_ access level will be restricted by
the containing type. For example: `internal struct S { public var i: Int }`
has a member that is _effectively_ internal.

The current rule for extensions is as follows: although extensions are a
scope for the purposes of "new private", they are not a first-class entity
and have no existence in the type system. As such, they cannot be the upper
limit for members. Instead, the access modifier for an extension is unique
in Swift: it is regarded as a "shorthand" for the default access modifier
for contained members and also the maximum permitted access level for those
members; for example, inside a "public extension" the members default to
public (not internal). Attempts to remove this behavior were fiercely
rejected by those who want to use the shorthand to have an extension full
of public members without restating "public".

If, however, it is a "private extension", then the default access modifier
for members in that extension is "fileprivate". This is correct *only* if
extensions can never be nested. There is no spelling for the maximum
possible visibility of a member inside a _nested_ private extension, and it
is not permitted to state an explicit access level greater than that of the
extension itself. If you want to support nested extensions, then this rule
cannot continue. However, previous attempts at harmonizing these rules were
not successful.


OK, I see your point, thank you for detailed description.

First, probably (as was discussed in this thread) we should disallow
'scoped' access level(current 'private') at top level of file. This IMO
will remove one of the big confusion point : 'scoped' will be allowed only
inside a scope less than file.
So, in this case, you'll have no "private extension"(current 'private') -
only "fileprivate extension" at top level.

(I'll use 'scoped' and 'fileprivate' below to be clear what I mean.
Currently they are 'private' and 'fileprivate', and probably will be
'scoped' and 'private')

Second - "There is no spelling for the maximum possible visibility of a
member inside a _nested_ private extension".. I.e. member with even
'public' access modifier in such extension will be effectively 'scoped' and
so nothing can be used outside of the extension ? If I understood correctly
- then it seems like we should just not allow 'scoped' for nested
extensions as such extension just has no sense.

So, both top level extensions and nested would have only 'fileprivate',
'internal' or 'public'. 'scoped' is not allowed for them(if we accept the
above suggestions):

class MyType { // internal
  public var a = 10 // internal(because of type's access level)
  var b = 20 // internal
  scoped var c = 30 // scoped for type and for nested extensions

  // default and max level is fileprivate, bounded by type's access level
  fileprivate extension MyProtoA {
scoped var d = 10 // scoped for extension, inaccessible outside  of it

var e = 20 // fileprivate
internal var f = 20 // fileprivate
public var g = 30 // fileprivate
  }

  // default and max level is internal, bounded by type's access level
  extension MyProtoB {
scoped var h = 40 // scoped for extension, inaccessible outside  of it

var i = 50 // internal
internal var j = 60 // internal
public var k = 70 // public->internal(type's access level)
  }

  // default and max level is public, bounded by type's access level
  public extension MyProtoC {
scoped var l = 80 // scoped for extension, inaccessible outside  of it

var m = 90 // public -> internal(type's access level)
internal var n = 100 // internal
public var o = 110 // public->internal(type's access level)
  }
}

Do you see any drawbacks in such design? (given that we disallow scoped
access modifier at top level of file and for nested extensions in type)



On Mon, Mar 27, 2017 at 15:59 Vladimir.S via swift-evolution
> wrote:

On 27.03.2017 20:00, Ross O'Brien via swift-evolution wrote:
> I'm considering this from a 

Re: [swift-evolution] [Pitch] String revision proposal #1

[Adrian Zubarev via swift-evolution]

I haven’t followed the topic and while reading the proposal I found it a little 
confusing that we have inconsistent type names. I’m not a native English 
speaker so that’s might be the main case for my confusion here, so I’d 
appreciate for any clarification. ;-)

SubSequence vs. Substring and not SubString.

The word substring is an English word, but so is subsequence (I double checked 
here).

So where exactly is the issue here? Is it SubSequence which is written in camel 
case or is it Substring which is not?



-- 
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 02:32:39, Ben Cohen via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi Swift Evolution,

Below is a pitch for the first part of the String revision. This covers a 
number of changes that would allow the basic internals to be overhauled.

Online version here: 
https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md


String Revision: Collection Conformance, C Interop, Transcoding

Proposal: SE-0161
Authors: Ben Cohen, Dave Abrahams
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal is to implement a subset of the changes from the Swift 4 String 
Manifesto.

Specifically:

Make String conform to BidirectionalCollection
Make String conform to RangeReplaceableCollection
Create a Substring type for String.SubSequence
Create a Unicode protocol to allow for generic operations over both types.
Consolidate on a concise set of C interop methods.
Revise the transcoding infrastructure.
Other existing aspects of String remain unchanged for the purposes of this 
proposal.

Motivation

This proposal follows up on a number of recommendations found in the manifesto:

Collection conformance was dropped from String in Swift 2. After reevaluation, 
the feeling is that the minor semantic discrepancies (mainly with 
RangeReplaceableCollection) are outweighed by the significant benefits of 
restoring these conformances. For more detail on the reasoning, see here

While it is not a collection, the Swift 3 string does have slicing operations. 
String is currently serving as its own subsequence, allowing substrings to 
share storage with their “owner”. This can lead to memory leaks when small 
substrings of larger strings are stored long-term (see here for more detail on 
this problem). Introducing a separate type of Substring to serve as 
String.Subsequence is recommended to resolve this issue, in a similar fashion 
to ArraySlice.

As noted in the manifesto, support for interoperation with nul-terminated C 
strings in Swift 3 is scattered and incoherent, with 6 ways to transform a C 
string into a String and four ways to do the inverse. These APIs should be 
replaced with a simpler set of methods on String.

Proposed solution

A new type, Substring, will be introduced. Similar to ArraySlice it will be 
documented as only for short- to medium-term storage:

Important

Long-term storage of Substring instances is discouraged. A substring holds a 
reference to the entire storage of a larger string, not just to the portion it 
presents, even after the original string’s lifetime ends. Long-term storage of 
a substring may therefore prolong the lifetime of elements that are no longer 
otherwise accessible, which can appear to be memory leakage.
Aside from minor differences, such as having a SubSequence of Self and a larger 
size to describe the range of the subsequence, Substring will be near-identical 
from a user perspective.

In order to be able to write extensions accross both String and Substring, a 
new Unicode protocol to which the two types will conform will be introduced. 
For the purposes of this proposal, Unicode will be defined as a protocol to be 
used whenver you would previously extend String. It should be possible to 
substitute extension Unicode { ... } in Swift 4 wherever extension String { ... 
} was written in Swift 3, with one exception: any passing of self into an API 
that takes a concrete String will need to be rewritten as String(self). If Self 
is a String then this should effectively optimize to a no-op, whereas if Self 
is a Substring then this will force a copy, helping to avoid the “memory leak” 
problems described above.

The exact nature of the protocol – such as which methods should be protocol 
requirements vs which can be implemented as protocol extensions, are considered 
implementation details and so not covered in this proposal.

Unicode will conform to BidirectionalCollection. RangeReplaceableCollection 
conformance will be added directly onto the String and Substring types, as it 
is possible future Unicode-conforming types might not be range-replaceable 
(e.g. an immutable type that wraps a const char *).

The C string interop methods will be updated to those described here: a single 
withCString operation and two init(cString:) constructors, one for UTF8 and one 
for arbitrary encodings. The primary change is to remove 

Re: [swift-evolution] Smart KeyPaths

[David Hart via swift-evolution]

> On 30 Mar 2017, at 09:41, Douglas Gregor  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Mar 29, 2017, at 10:35 PM, David Hart  wrote:
>> 
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution 
>>  wrote:
>> 
>>> Thanks for the feedback everyone!  We have pushed a changed a bit ago to 
>>> the proposal reflecting these desires.
>>> 
>>> https://github.com/apple/swift-evolution/pull/644/files
>>> 
>>> -Michael
>> 
>> I'm not a fan of the new syntax for creating key paths. To me, it feels like 
>> they've been demoted to second class citizens of the language simply because 
>> of how more verbose it now is. The new syntax is also too confusingly 
>> similar to string key paths: I had to look closely at the code to see the 
>> difference. Is there no symbol we can use to make it ambiguous? Ideas:
>> 
>> Person::friend.lastName
>> Person/friend.lastName
>> Person#friend.lastName
>> 
>> I'm a fan of the first one as it has similarities to names pacing in C++.
> 
> We might want to reserve :: for actual scope resolution. At least, we need 
> something to be able to disambiguate when the same name occurs as a member in 
> (e.g.) multiple protocols, and :: is familiar-ish. 

Perhaps, but I still believe we would gain a lot by keeping a similar syntax, 
whatever the separation token.

> I'm surprised nobody brought up making
> 
>   #keyPath(Person.friend.lastName)
> 
> Work as either a String or KeyPath. Probably a bad idea. 

If it works, would be better than the current version of the proposal IMHO, 
buts it's still fairly verbose for a feature that can become a first class 
citizen of the language. #keyPath was fine because it was an obscure objc 
bridging feature.

>  - Doug
> 
>> 
>> David.
>> 
> On Mar 29, 2017, at 2:49 PM, Douglas Gregor  wrote:
> 
> 
> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution 
>  wrote:
> 
> Hi friendly swift-evolution folks,
> 
> The Foundation and Swift team  would like for you to consider the 
> following proposal:
 
 
 The Swift core team discussed this proposal draft and had a little bit of 
 pre-review feedback.
 
> Access and Mutation Through KeyPaths
> To get or set values for a given root and key path we effectively add the 
> following subscripts to all Swift types. 
> 
> Swift
> extension Any {
> subscript(path: AnyKeyPath) -> Any? { get }
> subscript(path: PartialKeyPath) -> Any { get }
> subscript(path: KeyPath) -> Value { 
> get }
> subscript(path: WritableKeyPath) -> 
> Value { set, get }
> }
 
 Swift doesn’t currently have the ability to extend Any, so this is 
 (currently) pseudocode for compiler magic that one day we might be able to 
 place. Additionally, the “Root: Self” constraint isn’t something we 
 support in the generics system. A small note indicating that this is 
 pseudo-code meant to get the point across (rather than real code to drop 
 into the standard library/Foundation) would be appreciated.
 
 More importantly, this adds an unlabeled subscript to every type, which 
 raises concerns about introducing ambiguities—even if not hard ambiguities 
 that prevent code from compiling (e.g., from a Dictionary)---they can still show up in code completion, diagnostics, etc.
 
 The core team would prefer that this subscript distinguish itself more, 
 e.g., by labeling the first parameter “keyPath” (or some better name, if 
 there is one). Syntactically, that would look like:
 
person[keyPath: theKeyPathIHave]
 
> Referencing Key Paths
> 
> Forming a KeyPath borrows from the same syntax used to reference methods 
> and initializers,Type.instanceMethod only now working for properties and 
> collections. Optionals are handled via optional-chaining. Multiply dotted 
> expressions are allowed as well, and work just as if they were composed 
> via the appending methods on KeyPath.
> 
 The core team was concerned about the use of the Type.instanceProperty 
 syntax for a few reasons:
 
* It doesn’t work for forming keypaths to class/static properties (or 
 is ambiguous with the existing meaning(, so we would need another syntax 
 to deal with that case
* It’s quite subtle, even more so that the existing Type.instanceMethod 
 syntax for currying instance methods
 
> There is no change or interaction with the #keyPath() syntax introduced 
> in Swift 3. 
> 
 The core team felt that extending the #keyPath syntax was a better 
 syntactic direction to produce key-paths.
 
- Doug
 
>>> 
>>> ___
>>> 

Re: [swift-evolution] [Pitch] String revision proposal #1

[Brent Royal-Gordon via swift-evolution]

> On Mar 29, 2017, at 5:32 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi Swift Evolution,
> 
> Below is a pitch for the first part of the String revision. This covers a 
> number of changes that would allow the basic internals to be overhauled.
> 
> Online version here: 
> https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md

Really great stuff, guys. Thanks for your work on this!

> In order to be able to write extensions accross both String and Substring, a 
> new Unicode protocol to which the two types will conform will be introduced. 
> For the purposes of this proposal, Unicode will be defined as a protocol to 
> be used whenver you would previously extend String. It should be possible to 
> substitute extension Unicode { ... } in Swift 4 wherever extension String { 
> ... } was written in Swift 3, with one exception: any passing of self into an 
> API that takes a concrete String will need to be rewritten as String(self). 
> If Self is a String then this should effectively optimize to a no-op, whereas 
> if Self is a Substring then this will force a copy, helping to avoid the 
> “memory leak” problems described above.

I continue to feel that `Unicode` is the wrong name for this protocol, 
essentially because it sounds like a protocol for, say, a version of Unicode or 
some kind of encoding machinery instead of a Unicode string. I won't rehash 
that argument since I made it already in the manifesto thread, but I would like 
to make a couple new suggestions in this area.

Later on, you note that it would be nice to namespace many of these types:

> Several of the types related to String, such as the encodings, would ideally 
> reside inside a namespace rather than live at the top level of the standard 
> library. The best namespace for this is probably Unicode, but this is also 
> the name of the protocol. At some point if we gain the ability to nest enums 
> and types inside protocols, they should be moved there. Putting them inside 
> String or some other enum namespace is probably not worthwhile in the 
> mean-time.

Perhaps we should use an empty enum to create a `Unicode` namespace and then 
nest the protocol within it via typealias. If we do that, we can consider names 
like `Unicode.Collection` or even `Unicode.String` which would shadow existing 
types if they were top-level.

If not, then given this:

> The exact nature of the protocol – such as which methods should be protocol 
> requirements vs which can be implemented as protocol extensions, are 
> considered implementation details and so not covered in this proposal.

We may simply want to wait to choose a name. As the protocol develops, we may 
discover a theme in its requirements which would suggest a good name. For 
instance, we may realize that the core of what the protocol abstracts is 
grouping code units into characters, which might suggest a name like 
`Characters`, or `Unicode.Characters`, or `CharacterCollection`, or 
what-have-you.

(By the way, I hope that the eventual protocol requirements will be put through 
the review process, if only as an amendment, once they're determined.)

> Unicode will conform to BidirectionalCollection. RangeReplaceableCollection 
> conformance will be added directly onto the String and Substring types, as it 
> is possible future Unicode-conforming types might not be range-replaceable 
> (e.g. an immutable type that wraps a const char *).

I'm a little worried about this because it seems to imply that the protocol 
cannot include any mutation operations that aren't in 
`RangeReplaceableCollection`. For instance, it won't be possible to include an 
in-place `applyTransform` method in the protocol. Do you anticipate that being 
an issue? Might it be a good idea to define a parallel `Mutable` or 
`RangeReplaceable` protocol?

> The C string interop methods will be updated to those described here: a 
> single withCString operation and two init(cString:) constructors, one for 
> UTF8 and one for arbitrary encodings.

Sorry if I'm repeating something that was already discussed, but is there a 
reason you don't include a `withCString` variant for arbitrary encodings? It 
seems like an odd asymmetry.

> The standard library currently lacks a Latin1 codec, so a enum Latin1: 
> UnicodeEncoding type will be added.

Nice. I wrote one of those once; I'll enjoy deleting it.

> A new protocol, UnicodeEncoding, will be added to replace the current 
> UnicodeCodec protocol:
> 
> public enum UnicodeParseResult {

Either `T` should be given a more specific name, or the enum should be given a 
less specific one, becoming `ParseResult` and being oriented towards 
incremental parsing of anything from any kind of collection.

> /// Indicates valid input was recognized.
> ///
> /// `resumptionPoint` is the end of the parsed region
> case valid(T, resumptionPoint: Index)  // FIXME: should these be