Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jan 10, 2018 at 3:06 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I continue to have concerns about this proposal, and I'm gravely and very
> bitterly disappointed that the concerns have not even been acknowledged in
> the Alternatives section, which is in my view the minimum action that an
> author should take when points are raised during a pitch phase, even (and
> especially) when the author disagrees, along with a cogent write-up of why
> the proposed design is superior in the author's view to the alternative. In
> this case, the proposal authors write:
>
>   "The community has not raised any solutions whose APIs differ
> significantly from this proposal, except for solutions which provide
> strictly more functionality."
>
> This is false, as I have offered a solution in the past whose API differs
> entirely from this proposal, and which provides strictly a subset of the
> functionality which goes to the core of the issue at stake.
>
>
> I can't speak for the other co-authors, but for my part, this was an
> oversight and I apologize for it. I think we should have discussed your
> `MyType.self` alternative.
>

I echo Brent's sentiment — omissions were not intentionally disingenuous
but the result of a slow proposal writing/revision process, and clearly my
failure to adequately capture all of the mailing list discussion in the
proposal & alternatives even when it was updated in the days before the
review began. In the event the proposal is returned for revision, we can
revisit this to ensure all viewpoints are represented. Thanks, as always,
for your detailed reply.

Jacob


>
> I won't rehash the entire discussion in previous threads, but to summarize
> my objections:
>
> 1. `MyType.self` is harder to understand for someone who's never seen it
> than `MyType.allValues`. For instance, the expression
> `AccountStatus.allValues[0]` is completely self-explanatory, while
> `AccountStatus.self[0]` is more obscure and would require a trip to the
> documentation. (And since `self` here is a language keyword, not a real
> member, the most obvious route to the documentation is not available.) In
> my opinion, we should not prefer the `MyType.self` syntax.
>
> 2. Even if the community disagrees with me and thinks `MyType.self` is a
> better syntax than `MyType.allValues`, it is not better *enough* to
> outweigh the costs:
>
> • The metatype solution provides no additional functionality; it is merely
> a matter of which syntax we choose to support, and how much effort this
> support requires.
>
> • Conforming the metatype to `Collection` requires a lot of type system
> features we do not currently have. Currently, structural types cannot
> conform to protocols, and metatypes are a structural type. Metatypes also
> cannot have subscripts currently. Your proposed design has a lot of
> prerequisites. That is not in and of itself disqualifying, but it should be
> weighed against it.
>
> • You suggest that we should add bits and pieces of "`Collection`
> functionality" incrementally as engineering resources become available. The
> problem is that the most valuable part of the "`Collection` functionality"
> is conformance to `Collection` or at least `Sequence`, not the existence of
> any particular members of `Collection`, and this is the part that would
> require the most engineering resources.
>
> • A large part of the work we would do before supporting this conformance
> would be disposed of immediately once we could get it. For instance, all of
> the work to support having a metatype instead of a sequence in a `for-in`
> statement would be thrown away as soon as we could conform to `Sequence`.
> So this looks less like slowly building up pieces of the feature until we
> have all of them in place, and more like creating temporary hacks to
> emulate the feature until we have the time to do it right.
>
> • While this feature is not a showstopper, it is a highly desirable
> convenience. The proposal documents the high demand for this feature, so I
> won't elaborate on this point further.
>
> • Therefore, adopting this design would add a lot of engineering
> complexity before we could fully support a highly desirable feature, merely
> to get a syntax that we *might* prefer.
>
> To summarize the summary: The primary advantage of `MyType.self` is that
> it's elegant. To get that elegance, we must trade away getting a
> fully-functional implementation sooner, spending a lot of engineering
> resources (much of which would be wasted in the end), and—most crucially in
> my opinion—clarity at the point of use. It's not worth it.
>
> Earlier in this thread (or was it in the companion one?), another
> community member suggested that if `allValues` were to conform to
> `Sequence` instead of `Collection`, then even types that have an infinite
> number of possible values could conform to `V

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Jacob Bandes-Storch via swift-evolution]

Re-reading this thread and thinking about it more, I think I agree :)
Updating again...

On Sat, Dec 30, 2017 at 3:44 PM, Chris Lattner  wrote:

> On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sorry for the delay. I've just updated the proposal text to incorporate
> various changes, some contributed by others.
>
> https://github.com/jtbandes/swift-evolution/blob/case-
> enumerable/proposals/-derived-collection-of-enum-cases.md
>
>
> I would really love to see this happen.  I did a pass over the proposal, I
> strong suggest that you get Joe Groff’s input on this, because he has some
> opinions as well.
>
> IMO, the proposal looks really great except for one thing:   In "proposed
> solution”, I think it is very important that conformance to ValueEnumerable
> be explicitly requested in the code.  Specifically:
>
> enum Ma { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 }
> Ma.allValues   // error.
>
> enum Ma : ValueEnumerable { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 }
> Ma.allValues   // works!
>
>
> This is for two reasons:
> 1) Consistency with other similar features in Swift.  Types are not
> hashable just because their members could be.  This is because we want
> people to think about and explicitly opt into API features like this.
> 2) To align with our resilience design.  An enum with no value-associated
> cases today could acquire them in the future, and doing so would implicitly
> remove this conformance.  This would be surprising and bad.
>
> Thanks for pushing this forward!
>
> -Chris
>
>
>
>
>
>
> Robert's implementation
> <https://github.com/apple/swift-evolution/pull/114#issuecomment-337105126> is
> a good start, but will need to be updated to match the naming choice in the
> final proposal, and to use associatedtype.
>
> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher <
> schristop...@bignerdranch.com> wrote:
>
>> Has this stalled out again? I would like to help with the proposal and
>> even attempt implementation.
>>
>> I also need to catch up on the resilient discussion regarding enum case
>> ordering.
>>
>> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> Jacob Bandes-Storch
>>
>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <
>> br...@architechies.com> wrote:
>>
>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>>>
>>> 1. It must be possible to easily access the count of values, and to
>>>> access any particular value using contiguous `Int` indices. This could be
>>>> achieved either by directly accessing elements in the list of values
>>>> through an Int subscript, or by constructing an Array from the list of
>>>> values.
>>>>
>>>> 2. It must be possible to control the order of values in the list of
>>>> values, either by using source order or through some other simple,
>>>> straightforward mechanism.
>>>>
>>>
>>> OK, first of all, nowhere in the proposal text are these requirements
>>> stated as part of the use case. You're free to put forward new use cases,
>>> but here I am trying to design the most elegant way to fulfill a stated
>>> need and you're telling me that it's something other than what's written.
>>>
>>>
>>> Honestly, re-reading the proposal, it never cites a fully-formed use
>>> case. Instead, it cites several blog posts, Stack Overflow questions, and
>>> small code samples without digging in to the underlying reasons why
>>> developers are doing what they're doing. Most of the people discussing it
>>> so far seem to have had a tacit understanding that we wanted roughly
>>> Array-like access, but we haven't explicitly dug into which properties of
>>> an Array are important.
>>>
>>> (If anyone involved feels like they had a different understanding of the
>>> use case, please speak up.)
>>>
>>> I think this is a place where the proposal can be improved, and I'm
>>> willing to do some writing to improve it.
>>>
>>
>> For the record, I would be happy to add co-authors (or even relinquish
>> authorship entirely—I don't really care whose name is on this, it just
>> needs to happen!) if you or anyone else has improved wording, motivation,
>> justification, etc. to contribute.
>>
>> ___
>> 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] [swift-dev] Re-pitch: Deriving collections of enum cases

[Jacob Bandes-Storch via swift-evolution]

Sorry for the delay. I've just updated the proposal text to incorporate
various changes, some contributed by others.

https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md

Robert's implementation
<https://github.com/apple/swift-evolution/pull/114#issuecomment-337105126> is
a good start, but will need to be updated to match the naming choice in the
final proposal, and to use associatedtype.

On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher <
schristop...@bignerdranch.com> wrote:

> Has this stalled out again? I would like to help with the proposal and
> even attempt implementation.
>
> I also need to catch up on the resilient discussion regarding enum case
> ordering.
>
> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Jacob Bandes-Storch
>
> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <
> br...@architechies.com> wrote:
>
>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>>
>> 1. It must be possible to easily access the count of values, and to
>>> access any particular value using contiguous `Int` indices. This could be
>>> achieved either by directly accessing elements in the list of values
>>> through an Int subscript, or by constructing an Array from the list of
>>> values.
>>>
>>> 2. It must be possible to control the order of values in the list of
>>> values, either by using source order or through some other simple,
>>> straightforward mechanism.
>>>
>>
>> OK, first of all, nowhere in the proposal text are these requirements
>> stated as part of the use case. You're free to put forward new use cases,
>> but here I am trying to design the most elegant way to fulfill a stated
>> need and you're telling me that it's something other than what's written.
>>
>>
>> Honestly, re-reading the proposal, it never cites a fully-formed use
>> case. Instead, it cites several blog posts, Stack Overflow questions, and
>> small code samples without digging in to the underlying reasons why
>> developers are doing what they're doing. Most of the people discussing it
>> so far seem to have had a tacit understanding that we wanted roughly
>> Array-like access, but we haven't explicitly dug into which properties of
>> an Array are important.
>>
>> (If anyone involved feels like they had a different understanding of the
>> use case, please speak up.)
>>
>> I think this is a place where the proposal can be improved, and I'm
>> willing to do some writing to improve it.
>>
>
> For the record, I would be happy to add co-authors (or even relinquish
> authorship entirely—I don't really care whose name is on this, it just
> needs to happen!) if you or anyone else has improved wording, motivation,
> justification, etc. to contribute.
>
> ___
> 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] [swift-dev] Re-pitch: Deriving collections of enum cases

[Jacob Bandes-Storch via swift-evolution]

Jacob Bandes-Storch

On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon 
wrote:

> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>
> 1. It must be possible to easily access the count of values, and to access
>> any particular value using contiguous `Int` indices. This could be achieved
>> either by directly accessing elements in the list of values through an Int
>> subscript, or by constructing an Array from the list of values.
>>
>> 2. It must be possible to control the order of values in the list of
>> values, either by using source order or through some other simple,
>> straightforward mechanism.
>>
>
> OK, first of all, nowhere in the proposal text are these requirements
> stated as part of the use case. You're free to put forward new use cases,
> but here I am trying to design the most elegant way to fulfill a stated
> need and you're telling me that it's something other than what's written.
>
>
> Honestly, re-reading the proposal, it never cites a fully-formed use case.
> Instead, it cites several blog posts, Stack Overflow questions, and small
> code samples without digging in to the underlying reasons why developers
> are doing what they're doing. Most of the people discussing it so far seem
> to have had a tacit understanding that we wanted roughly Array-like access,
> but we haven't explicitly dug into which properties of an Array are
> important.
>
> (If anyone involved feels like they had a different understanding of the
> use case, please speak up.)
>
> I think this is a place where the proposal can be improved, and I'm
> willing to do some writing to improve it.
>

For the record, I would be happy to add co-authors (or even relinquish
authorship entirely—I don't really care whose name is on this, it just
needs to happen!) if you or anyone else has improved wording, motivation,
justification, etc. to contribute.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Re-pitch: Deriving collections of enum cases

[Jacob Bandes-Storch via swift-evolution]

Over a year ago, we discussed adding a magic "allValues"/"allCases" static
property on enums with a compiler-derived implementation. The original proposal
PR  has been reopened
for Swift 5 after languishing for a while, and I'd like to revisit it and
make some changes before it goes up for formal review.

Prior discussion:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015098.html
(good luck finding the rest of the thread if you weren't on the list at the
time...)

[cc'd swift-dev for importer/availability-related topics below.]

***Naming***

Given the complexity gap between a simple enumeration of cases and full
support for non-enum types and associated values (which we don't intend to
support with this proposal), I think it might be a good idea to adopt the
names *CaseEnumerable/allCases* instead of ValueEnumerable/allValues.

The original proposal didn't expose allValues as a requirement, for fear of
unduly restricting its type. However, if the protocol's scope is more
limited, *static var allCases* can be exposed as a requirement since the
implementations are not likely to be complex. Furthermore...


***Generics***

Since SE-0142

was implemented in Swift 4, we now have more expressive options for the
protocol requirements:

  // 1 - array only
  protocol CaseEnumerable {
static var allCases: [Self] { get }
  }

  // 2 - any sequence
  protocol CaseEnumerable {
associatedtype *CaseSequence*: Sequence where CaseSequence.Element ==
Self
static var *allCases*: CaseSequence { get }
  }

  // 3 - any collection
  protocol CaseEnumerable {
associatedtype *CaseCollection*: Collection where
CaseCollection.Element == Self
static var *allCases*: CaseCollection { get }
  }

This restricts the CaseEnumerable protocol to be used as a generic
constraint, but that'd be true even with a plain array because of the Self
type.

Personally I like the flexibility provided by the associatedtype, but I
also recognize it won't be incredibly useful for enums — more so if we
wanted to provide e.g. UInt8.allValues, whose ideal implementation might be
"return 0...UInt8.max". So I could see allowing allValues to be any
sequence or collection, but flexibility for allCases might be less
important. Others should weigh in here.


***Implementation strategy and edge cases***

Last year , Robert
Widmann put together an implementation of CaseEnumerable:
https://github.com/apple/swift/compare/master...CodaFi:ace-attorney
I'd love to hear from anyone more familiar with the code whether there's
anything we'd want to change about this approach.

A few tricky situations have been brought to my attention:

- Enums *imported from C/Obj-C* headers. Doug Gregor writes: *"The
autogenerated allValues would only be able to list the enum cases it knows
about from the header it was compiled with. If the library changes to
add cases in the future (which, for example, Apple frameworks tend to do),
those wouldn’t be captured in allValues."*

My understanding of the runtime/importer is very shallow, but with the
current metadata-based strategy, I suspect imported enums couldn't be
supported at all, or if they could, the metadata would be generated at
import time rather than loaded dynamically from the library, which
naturally wouldn't behave the same way when you drop in an upgraded version
of the library. Is that correct?

(Nonetheless, if a user really wanted this auto-generation, it would be
nice to allow it somehow. Personally, I have had enums whose "source of
truth" was an Obj-C header file, but since it was compiled in with the rest
of the application, we didn't care at all about library upgrades. Maybe an
internal extension adding a conformance can be allowed to participate in
auto-generation?)

- Enums with *availability* annotations on some cases. Doug Gregor writes: *"if
I have a case that’s only available on macOS 10.12 and newer, it probably
shouldn’t show up if I use allValues when running on macOS 10.11."*

If we fetch cases from the enum metadata, does this "just work" since the
metadata will be coming from whichever version of the library is loaded at
runtime? If not, is it at least *possible* to extract availability info
from the metadata? Finally, if not, should we try to synthesize an
implementation that uses #available checks, or just refuse to synthesize
allCases?

- Should it be possible to add a CaseEnumerable conformance in an
*extension*? My thinking is: we want to make sure the metadata is coming
from the module that defines the enum, so we could restrict autogeneration
of allCases to that same module. (That is, it wouldn't be possible to
synthesize allCases for a CaseEnumerable extension on an enum from another
module.) Although, it may be that I am missing something and this
res

Re: [swift-evolution] [Pitch] Guard/Catch

[Jacob Bandes-Storch via swift-evolution]

Some prior, probably not as well thought-through, discussion on this topic:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011446.html
On Wed, Jul 5, 2017 at 10:40 AM Soroush Khanlou via swift-evolution <
swift-evolution@swift.org> wrote:

> I’d like to propose a guard/catch construct to the language. It would
> allow code to use throwing functions and handle errors fully, without
> straying from a happy path. do/catch can be a bit heavy-handed sometimes,
> and it would be nice to be able to handle throwing functions without
> committing to all the nesting and ceremony of do/catch.
>
> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9
>
> Looking forward to feedback!
>
> Soroush
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Bandes-Storch via swift-evolution]

I've found a similar thing useful, but with Errors instead of fatalErroring:

infix operator ?! : NilCoalescingPrecedence

func ?!(lhs: T?, rhs: @autoclosure () -> Error) throws -> T {
if let lhs = lhs { return lhs }
throw rhs()
}

let x = try failableFunc() ?! MyError.somethingFailed


On Tue, Jun 27, 2017 at 10:29 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 I had a slightly different implementation.
>
> https://gist.github.com/DevAndArtist/dad641ee833e60b02fd1db2dbb488c6a
>
> //
> // UnwrapOrTrap.swift
> //
> infix operator ?! : NilCoalescingPrecedence
>
> /// Performs a nil-coalescing operation, returning the wrapped value of an
> /// `Optional` instance or uses the rhs function to stop the program.
> ///
> /// - Parameters:
> ///   - optional: An optional value.
> ///   - noreturn: A function to stop the programm.
> func ?!(optional: T?, noreturn: @autoclosure () -> Never) -> T {
>switch optional {
>case .some(let value):
>   return value
>case .none:
>   noreturn()
>}
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 27. Juni 2017 um 19:25:15, Erica Sadun via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Using an operator to provide feedback on the context of a failed unwrap
> has become a commonly implemented approach in the Swift developer
> Community. What are your thoughts about adopting this widely-used operator
> into the standard library?
>
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
>
> Details here:  https://gist.github.com/erica/
> 423e4b1c63b95c4c90338cdff4939a9b
>
> Thank you for your thoughtful feedback, -- E
>
> ___
> 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] [Announcement] Godbolt Compiler Explorer adds Swift support

[Jacob Bandes-Storch via swift-evolution]

Awesome! :)

3.1.1 is a great start — any plans to include recent nightly builds of the
compiler, similar to IBM's Swift Sandbox
?

On Thu, Jun 22, 2017 at 10:24 AM, Adam Nemecek via swift-evolution <
swift-evolution@swift.org> wrote:

> Howdy,
> Matt Godbolt and I have added Swift support to his compiler explorer
> project
>
> https://swift.godbolt.org/
>
> It let's you interactively explore assembly emitted by the Swift compiler.
>
> Right now, if you want the compiler to emit Intel syntax instructions,
> pass "-emit-assembly -Xllvm --x86-asm-syntax=intel" to the compiler as a
> command line argument in the text field in the top right corner.
>
> Note that right now it's might still be kinda rough around the edges.
>
> You can contribute to the project here https://github.com/mattgo
> dbolt/compiler-explorer
>
> Adam
>
> ___
> 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] Swift phases and mis-timed proposals

[Jacob Bandes-Storch via swift-evolution]

On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

> I support everything Jon wrote.
>
> +1 Free-for-all brainstorming venue separate from focused proposal
> discussion.
>

+1, particularly for this being a section in Discourse ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Jacob Bandes-Storch via swift-evolution]

Now that escaping with \ has been proposed for KeyPaths, this makes me
wonder whether it would be appropriate to use "\foo()" rather than
"foo(_)"/"foo(:)" ?  It still feels a bit strange, as \foo() looks like
escaping the *result* of a call.


On Sat, Feb 25, 2017 at 1:43 PM, David Hart  wrote:

>
> On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don't have a *good* answer for this, but I'll vote *against* 'foo(:)'
> because that's what a lot of people think the name of 'foo(_:)' should be.
> I'd rather be able to offer fix-its for that even when you have both
> 'foo()' and 'foo(_:)' defined. I'd rather go with 'foo(_)' despite the tiny
> ambiguity in pattern contexts.
>
> (I'm personally in favor of killing unapplied function references
> altogether in favor of closures, on the grounds that they are overly terse,
> make type-checking more complicated, and often lead to retain cycles. Then
> we'd only need this for #selector, and it's perfectly unambiguous to use
> 'foo()' there. But I wasn't planning to fight that particular battle now,
> and it is rather annoying to require the 'as' in the meantime.)
>
>
> It is potentially going to be hard to fight that battle. I think a lot of
> functional/Haskell people love them and would be sad to see them go away (I
> plead guilty). But it isn’t a well known part of the language so I don’t
> think the general community would miss it.
>
> Jordan
>
>
> On Feb 21, 2017, at 23:05, Jacob Bandes-Storch  wrote:
>
> Evolutioniers,
>
> *Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
> disambiguate references to functions. (You might've used it inside a
> #selector expression.) But there's currently no compound name for a
> function with no arguments.
>
> func foo() {}  // no compound syntax for this one :(
> func foo(_ bar: Int) {}  // foo(_:)
> func foo(bar: Int) {}  // foo(bar:)
> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
>
> Given these four functions, only the first one has no compound name
> syntax. And the simple reference "let myfn = foo" is ambiguous because it
> could refer to any of the four. A workaround is to specify a contextual
> type, e.g. "let myfn = foo as () -> Void".
>
> I filed SR-3550  for this a while
> ago, and there was some discussion in JIRA about it. I'd like to continue
> exploring solutions here and then write up a formal proposal.
>
> To kick off the discussion, *I'd like to propose foo(:) for nullary
> functions.*
>
> Advantages:
> - the colon marks a clear similarity to the foo(bar:) form when argument
> labels are present.
> - cutely parallels the empty dictionary literal, [:].
>
> Disadvantages:
> - violates intuition about one-colon-per-argument.
> - the parallel between #selector(foo(:)) and @selector(foo) is not quite
> as obvious as between #selector(foo(_:)) and @selector(foo:).
>
>
> For the sake of discussion, another option would be *foo(_)*. This was my
> original choice, and I like that the number of colons matches the number of
> parameters. However, it's a little less obvious as a function reference. It
> would preclude _ from acting as an actual identifier, and might conflict
> with pattern-matching syntax (although it appears functions can't be
> compared with ~= anyway).
>
>
> Looking forward to everyone's bikeshed color ideas,
> Jacob
>
>
> ___
> 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] 'Random' Improvements

[Jacob Bandes-Storch via swift-evolution]

Directly copying a swift-evolution email I sent almost exactly a year ago:

I encourage anyone thinking about PRNG APIs to check out what C++ STL has
> to offer: http://en.cppreference.com/w/cpp/numeric/random
> And this analysis/extension of it: http://www.pcg-random.org/
> posts/ease-of-use-without-loss-of-power.html



I also found Milos Rankovic's response worth considering:
https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160404/001676.html

-Jacob

On Wed, Apr 5, 2017 at 10:25 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 5, 2017, at 7:00 PM, Peter Dillinger via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Haha:
> >
> >> https://lists.swift.org/pipermail/swift-evolution/Week-of-
> Mon-20170227/033482.html
> >>
> >> In general, I’d recommend against providing a default that we know
> won’t meet everyone’s needs,
> >> as randomness can have security properties.
> >
> > The same could be said of Hashable and even String concatenation, and
> bad randomness isn't even in the OWAP Top 10 (by my reading).
>
> Making some "mistakes" in the past shouldn't encourage to make them in the
> present.
>
> >
> > --
> > Peter Dillinger, Ph.D.
> > Software Engineering Manager, Coverity Analysis, Software Integrity
> Group | Synopsys
> > www.synopsys.com/software
> >
> >
> > ___
> > 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] [Draft] Fix ExpressibleByStringInterpolation

[Jacob Bandes-Storch via swift-evolution]

On Sat, Mar 11, 2017 at 5:34 AM, Brent Royal-Gordon 
wrote:

> > On Mar 10, 2017, at 11:17 PM, Jacob Bandes-Storch 
> wrote:
> >
> > I'm confused by this example — was 
> > ExpressibleByFailableStringInterpolation's
> init() supposed to be failable here?
>
> Ugh, yes, I'm sorry. That should have been:
>
> protocol ExpressibleByFailableStringInterpolation:
> ExpressibleByStringLiteral {
> associatedtype StringInterpolationType
>
> init?(stringInterpolation: StringInterpolationSegment...)
> }
>
> ...
>
> extension Optional: ExpressibleByStringInterpolation where
> Wrapped: ExpressibleByFailableStringInterpolation {
> typealias StringLiteralType = Wrapped.StringLiteralType
> typealias StringInterpolationType =
> Wrapped.StringInterpolationType
>
> init(stringInterpolation segments:
> StringInterpolationSegment...) {
> self = Wrapped(stringInterpolation: segments)
> }
> }
>
> > Just to throw out another idea, what about keeping the entirety of the
> string in one contiguous block and providing String.Indexes to the
> initializer?
> >
> > protocol ExpressibleByStringInterpolation {
> > associatedtype Interpolation
> > init(_ string: String, with interpolations: (String.Index,
> Interpolation)...)
> > }
>
> I've thought about that too. It's a little bit limiting—you have no choice
> except to use `String` as your input type. Also, the obvious way to use
> these parameters:
>
> init(stringLiteral string: String, with interpolations:
> (String.Index, Interpolation)...) {
> var copy = string
> for (i, expr) in interpolations {
> let exprString = doSomething(with: expr)
> copy.insert(exprString, at: i)
> }
> self.string = copy
> }
>
> Will probably be slow, since you're inserting into the middle instead of
> appending to the end. Obviously a clever programmer can avoid doing that,
> but why create the attractive nuisance in the first place?
>

It's also easy to get wrong ;-)  Docs for insert(_:at:) say "Calling this
method invalidates any existing indices for use with this string." And even
if they weren't invalidated, but simple numerical indices as into an Array,
you'd need to use them offsetBy however much content you'd inserted so far.


>
> > On the other hand, unless I've missed something, it seems like most of
> the suggestions so far are assuming that for any
> ExpressibleByStringInterpolation type, the interpolated values' types
> will be homogeneous. In the hypothetical printf-replacement case, you'd
> really want the value types to depend on the format specifiers, so that a
> Float couldn't be passed to %d without explicitly converting to an integer
> type.
> >
> > Although I suppose that could simply be achieved with a typealias
> Interpolation = enum { case f(Float), d(Int), ... }
>
>
> Yup. Given Swift's current feature set, the only way to design this is to
> have a single type which all interpolations funnel through. That type could
> be `Any`, of course, but that doesn't really help anybody.
>
> If we had variadic generics, you could of course have a variadic
> initializer with heterogeneous types. And I've often given thought to a
> "multiple associated types" feature where a protocol could be conformed to
> multiple times by specifying more than one concrete type for specific
> associated types. But these are both exotic features. In their absence, an
> enum (or something like that) is probably the best choice.
>
> * * *
>
> I'm going to try to explore some of these other designs, but they all seem
> to assume the new formatting system I sketched out in "future directions",
> so I implemented that first:
>
> https://github.com/brentdax/swift/compare/new-interpolation.
> ..brentdax:new-interpolation-formatting
>
> The switch to `\(describing: foo)` has more impact than I expected; just
> the code that's built by `utils/build-script`—not including tests—has over
> a hundred lines with changes like this:
>
> -expectationFailure("\(lhs) < \(rhs)", trace: ${trace})
> +expectationFailure("\(describing: lhs) < \(describing: rhs)", trace:
> ${trace})
>
> On the other hand, I like what it does to other formatting (I've only
> applied this kind of change in a few places):
>
> -return "CollectionOfOne(\(String(reflecting: _element)))"
> +return "CollectionOfOne(\(reflecting: _element))"
>
> And it *does* make you think about whether you want to use `describing:`
> or `reflecting:`:
>
> -expectEqual(expected, actual, "where the argument is: \(a)")
> +expectEqual(expected, actual, "where the argument is: \(describing:
> a)")
>
> And, thanks to LosslessStringConvertible, it also does a pretty good job
> of calling out the difference between interpolations that will probably
> look good to 

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

[Jacob Bandes-Storch via swift-evolution]

On Fri, Mar 10, 2017 at 4:44 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Mar 10, 2017, at 8:49 AM, Joe Groff  wrote:
> >
> > I think there's a more powerful alternative design you should also
> consider. If the protocol looked like this:
> >
> > protocol ExpressibleByStringInterpolation: ExpressibleByStringLiteral {
> >   associatedtype LiteralSegment: ExpressibleByStringLiteral
> >   associatedtype InterpolatedSegment
> >   init(forStringInterpolation: Void)
> >
> >   mutating func append(literalSegment: LiteralSegment)
> >   mutating func append(interpolatedSegment: InterpolatedSegment)
> > }
> >
> > Then an interpolation expression like this in `Thingy` type context:
> >
> > "foo \(bar) bas \(zim: 1, zang: 2)\n"
> >
> > could desugar to something like:
> >
> > {
> >   var x = Thingy(forStringInterpolation: ())
> >   // Literal segments get appended using append(literalSegment:
> "literal")
> >   x.append(literalSegment: "foo ")
> >   // \(...) segments are arguments to a InterpolatedSegment constructor
> >   x.append(interpolatedSegment: Thingy.InterpolatedSegment(bar))
> >   x.append(literalSegment: " bas ")
> >   x.append(interpolatedSegment: Thingy.InterpolatedSegment(zim: 1,
> zang: 2))
> >
> >   return x
> > }()
> >
> > This design should be more efficient, since there's no temporary array
> of segments that needs to be formed for a variadic argument, you don't need
> to homogenize everything to Self type up front, and the string can be built
> up in-place. It also provides means to address problems 3 and 4, since the
> InterpolatedSegment associated type can control what types it's
> initializable from, and can provide initializers with additional arguments
> for formatting or other purposes.
>
> On the other hand, you end up with an `init(forStringInterpolation: ())`
> initializer which is explicitly intended to return an incompletely
> initialized instance. I don't enjoy imagining this. For instance, you might
> find yourself having to change certain properties from `let` to `var` so
> that the `append` methods can operate.
>
> If we *do* go this direction, though, I might suggest a slightly different
> design which uses fewer calls and makes the finalization explicit:
>
> protocol ExpressibleByStringLiteral {
> associatedtype StringLiteralSegment:
> ExpressibleByStringLiteral
>
> init(startingStringLiteral: ())
> func endStringLiteral(with segment: StringLiteralSegment)
> }
> protocol ExpressibleByStringInterpolation:
> ExpressibleByStringLiteral {
> associatedtype StringInterpolationSegment
>
> func continueStringLiteral(with literal:
> StringLiteralSegment, followedBy interpolation: StringInterpolationSegment)
> }
>
> Your `"foo \(bar) bas \(zim: 1, zang: 2)\n"` example would then become:
>
> {
> var x = Thingy(startingStringLiteral: ())
> x.continueStringLiteral(with: "Foo ", followedBy:
> .init(bar))
> x.continueStringLiteral(with: " bas ", followedBy:
> .init(zim: 1, zang: 2))
> x.endStringLiteral(with: "\n")
> return x
> }
>
> While a plain old string literal would have a more complicated pattern
> than they do currently, but one which would have completely compatible
> semantics with an interpolated string:
>
> {
> var x = Thingy(startingStringLiteral: ())
> x.endStringLiteral(with: "Hello, world!")
> return x
> }
>
> * * *
>
> Another possible design would separate the intermediate type from the
> final one. For instance, suppose we had:
>
> protocol ExpressibleByStringInterpolation:
> ExpressibleByStringLiteral {
> associatedtype StringInterpolationBuffer = Self
> associatedtype StringInterpolationType
>
> static func makeStringLiteralBuffer(startingWith
> firstLiteralSegment: StringLiteralType) -> StringLiteralBuffer
> static func appendInterpolationSegment(_ expr:
> StringInterpolationType, to stringLiteralBuffer: inout StringLiteralBuffer)
> static func appendLiteralSegment(_ string:
> StringLiteralType, to stringLiteralBuffer: inout StringLiteralBuffer)
>
> init(stringInterpolation buffer: StringInterpolationBuffer)
> }
> // Automatically provide a parent protocol conformance
> extension ExpressibleByStringInterpolation {
> init(stringLiteral: StringLiteralType) {
> let buffer = 
> Self.makeStringLiteralBuffer(startingWith:
> stringLiteral)
> self.init(stringInterpolation: buffer)
> }
> }
>
> Then your example would be:
>
> {
> var buffer = Thingy.makeStringLiteralBuffer(startingWith:
> "foo ")
> Thingy.appendInterpolatio

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Jacob Bandes-Storch via swift-evolution]

This is clean, but given knowledge of foo(bar:) syntax, its discoverability
is low. Conversely, given knowledge of `foo()`, the discoverability of
foo(bar:) would be low compared to `foo(bar:)`.

If backticks were the *only* option, and also worked as `foo(bar:)`, the
consistency would be appealing. Although then if you had a function name
which needed backticks,  `foo`(bar:) would have to continue working, I
suppose, so only allowing `foo(bar:)` isn't feasible.

I imagine this would make for some very nice code completion, though —
`foo(#^...^#  could suggest the names of all the foo variants.


On Thu, Feb 23, 2017 at 6:36 AM, Ben Rimmington 
wrote:

>
> > On 23 Feb 2017, at 14:23, Xiaodi Wu wrote:
> >
> > What happens when you need the backticks for the function name itself?
> We can't nest them.
>
> func `class`() {}
>
> `class`() // Function call.
>
> `class()` // Function reference.
>
> -- Ben
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Jacob Bandes-Storch via swift-evolution]

Just to throw out some other options: foo(#) and foo(@).

(And you thought we'd gotten rid of # argument labels! 😉)

On Wed, Feb 22, 2017 at 11:48 AM David Sweeris  wrote:

>
> > On Feb 22, 2017, at 11:05 AM, Matthew Johnson 
> wrote:
> >
> >
> >> On Feb 22, 2017, at 12:30 PM, David Sweeris 
> wrote:
> >>
> >>
> >>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I like this idea.  I think you made the right choice of syntax given
> the alternatives considered.  To me `foo(_)` and `foo(:)` equally imply
> presence of an argument.  The former looks like an anonymous (unnamed)
> argument and the latter includes the colon which only follows an argument.
> Between the two `foo(:)` is the better choice because it doesn’t look like
> a pattern as has been pointed out.
> >>>
> >>> I’m going to do a little brainstorming to try and come up with
> something that works and doesn’t imply an argument at all but suspect I’ll
> come up empty handed.
> >>
> >> What about “foo(Void)”? It might be fairly easily confused with
> “foo(:Void)”, but in practice, how likely is it for someone to declare both
> `foo()` and `foo(_: Void)`?
> >
> > I almost threw out `foo(Void)` and `foo(Never)` as ideas.  There is at
> least one problem with these.  We will hopefully eventually get rid of the
> need to say `.self` in expressions like `Int.self`.  If we are able to do
> that then `foo(Void)` and `foo(Never)` are syntactically valid function
> calls.
>
> Oh, good point! Hrmm… “foo(#null)”/“foo(#nullary)"? I can’t imagine either
> of those would ever be valid function calls, and they get the point across
> (the later more than the former, but it’s more to type). I don’t like that
> syntax for the name of “shortest” version of the function isn’t shorter
> than the syntax of the name for other versions of the function, though.
>
> - Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Jacob Bandes-Storch via swift-evolution]

There were some opinions on Slack that we should simply change `foo` so
that it can *only* refer to the nullary version.

That'd be a source-breaking change, but I'm also not sure whether it's even
solve the problem — is it true you might still have both a function and a
variable named foo accessible in the same scope?
On Wed, Feb 22, 2017 at 11:48 AM David Sweeris  wrote:

>
> > On Feb 22, 2017, at 11:05 AM, Matthew Johnson 
> wrote:
> >
> >
> >> On Feb 22, 2017, at 12:30 PM, David Sweeris 
> wrote:
> >>
> >>
> >>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I like this idea.  I think you made the right choice of syntax given
> the alternatives considered.  To me `foo(_)` and `foo(:)` equally imply
> presence of an argument.  The former looks like an anonymous (unnamed)
> argument and the latter includes the colon which only follows an argument.
> Between the two `foo(:)` is the better choice because it doesn’t look like
> a pattern as has been pointed out.
> >>>
> >>> I’m going to do a little brainstorming to try and come up with
> something that works and doesn’t imply an argument at all but suspect I’ll
> come up empty handed.
> >>
> >> What about “foo(Void)”? It might be fairly easily confused with
> “foo(:Void)”, but in practice, how likely is it for someone to declare both
> `foo()` and `foo(_: Void)`?
> >
> > I almost threw out `foo(Void)` and `foo(Never)` as ideas.  There is at
> least one problem with these.  We will hopefully eventually get rid of the
> need to say `.self` in expressions like `Int.self`.  If we are able to do
> that then `foo(Void)` and `foo(Never)` are syntactically valid function
> calls.
>
> Oh, good point! Hrmm… “foo(#null)”/“foo(#nullary)"? I can’t imagine either
> of those would ever be valid function calls, and they get the point across
> (the later more than the former, but it’s more to type). I don’t like that
> syntax for the name of “shortest” version of the function isn’t shorter
> than the syntax of the name for other versions of the function, though.
>
> - Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Allowing extending existentials

[Jacob Bandes-Storch via swift-evolution]

This works today:

protocol P1{}
protocol P2{}

extension P1 where Self: P2 {
func foo() {}
}

func bar(x: P1 & P2) {
x.foo()
}


On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello list,
>
> Found out yesterday that you can’t extend all existentials in Swift:
>
> protocol P1 {}
> extension P1 {}
> // works as expected
>
> protocol P2 {}
> extension P1 & P2 {}
> // error: non-nominal type 'P1 & P2' cannot be extended
>
> extension Any {}
> // error: non-nominal type 'Any' cannot be extended
>
> extension AnyObject {}
> // error: 'AnyObject' protocol cannot be extended
>
> I’d like to write a proposal to lift some of those restrictions. But the
> question is: which should be lifted? P1 & P2 seems like an obvious case.
> But what about Any and AnyObject? Is there a design reason that we
> shouldn’t allow it?
>
> David.
>
> ___
> 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: Compound name `foo(:)` for nullary functions

[Jacob Bandes-Storch via swift-evolution]

Evolutioniers,

*Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
disambiguate references to functions. (You might've used it inside a
#selector expression.) But there's currently no compound name for a
function with no arguments.

func foo() {}  // no compound syntax for this one :(
func foo(_ bar: Int) {}  // foo(_:)
func foo(bar: Int) {}  // foo(bar:)
func foo(bar: String, baz: Double) {}  // foo(bar:baz:)

Given these four functions, only the first one has no compound name syntax.
And the simple reference "let myfn = foo" is ambiguous because it could
refer to any of the four. A workaround is to specify a contextual type,
e.g. "let myfn = foo as () -> Void".

I filed SR-3550  for this a while
ago, and there was some discussion in JIRA about it. I'd like to continue
exploring solutions here and then write up a formal proposal.

To kick off the discussion, *I'd like to propose foo(:) for nullary
functions.*

Advantages:
- the colon marks a clear similarity to the foo(bar:) form when argument
labels are present.
- cutely parallels the empty dictionary literal, [:].

Disadvantages:
- violates intuition about one-colon-per-argument.
- the parallel between #selector(foo(:)) and @selector(foo) is not quite as
obvious as between #selector(foo(_:)) and @selector(foo:).


For the sake of discussion, another option would be *foo(_)*. This was my
original choice, and I like that the number of colons matches the number of
parameters. However, it's a little less obvious as a function reference. It
would preclude _ from acting as an actual identifier, and might conflict
with pattern-matching syntax (although it appears functions can't be
compared with ~= anyway).


Looking forward to everyone's bikeshed color ideas,
Jacob
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Jacob Bandes-Storch via swift-evolution]

On Sat, Feb 18, 2017 at 8:49 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm on vacation and don't have time for a full review right now, but I am
> concerned that wild this proposal would make enums more general and uniform
> with the rest of the language , they also would become much more awkward
> for common use cases. I have recently been very pleased that I didn't have
> to supply labels in switch statements where the label name would simply
> have matched the name of the variable to be bound.  This looks needlessly
> verbose:
>
>   case .valid(value: let value, resumptionPoint: let resumptionPoint):
>
> I cannot imagine a real life use case where one would have labels in the
> case and desire to bind associated values to variables having different
> names than the labels.
>

What about something like this? It's a bit contrived, but the point is you
could easily expect to work with more than one value of the same enum type
at the same time.

enum Color {
  case rgb(red: Double, green: Double, blue: Double)
  ...

  func interpolated(to other: Color, by fraction: Double) -> Color {
switch (self, other) {
case (.rgb(red: let red, blue: let blue, green: let green),
  .rgb(red: let otherRed, blue: let otherBlue, green: let
otherGreen)):
  return .rgb(
red: lerp(from: red, to: otherRed, by: fraction),
...)
...
}
  }
}


Your point, though, reminds me of ES6 destructuring assignment, e.g. "let
{red, green} = color", and inversely a syntax whose name I don't know, "let
color = {red, green}", which are indeed quite convenient when variable
names match object key names.



> Secondly, I can't imagine a case where one would want to use the same case
> basename and different labels. The very common use case where the types of
> associated values completely distinguish the case and one would rather not
> have to supply a case name at all is completely unaddressed. If my quick
> read is not mistaken, this proposal makes it legal for cases to have
> different *complete names* (including base name and labels), but doesn't
> make it legal to have the same full name (which I would love to be "_" or
> missing in some cases) with different associated value types. If we were
> truly following the precedent set by function signatures, wouldn't that be
> possible too?
>
> Sent from my moss-covered three-handled family gradunza
>
> On Feb 17, 2017, at 5:26 PM, John McCall  wrote:
>
> Hello Swift community,
>
> The review of "SE-0155: Normalize Enum Case Representation" begins now and
> runs through next Friday, February 26th. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposa
> ls/0155-normalize-enum-case-representation.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/0155-normalize-enum-case-representation.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,
>
> John McCall
> Review Manager
>
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>
> ___
> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

On Tue, Feb 7, 2017 at 1:15 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> Believe it or not, not everyone in the world can afford the device and
> data plan for a JavaScript-rich web front end (I'm aware of the mobile
> apps). I remember only being able to buy an iPod Touch myself when it came
> out. I *would* be able to participate SE if it existed back then. Because
> email is so old and work well in offline environment.
>
>
> I have full comprehension for those who want to keep their email workflow
> as it is, but as it has been pointed out many times before: Discourse has
> support for that… (and it's a little bit annoying to see many fans of email
> ignoring this fact in their argumentation over and over).
>

This isn't really fair; while Discourse does have email support, it is not
perfect, and would not be a "first-class" experience for those who are
inclined to continue using mail clients. We tested

this

on Nate's demo site. As some have pointed out, the emails are less "raw" in
that they have some Discourse UI on top of the actual content, and more
importantly, inline replies do not work very well (unless someone wants to
drastically improve the email parser
).

Personally I believe that the benefits vastly outweigh these drawbacks, but
other than enumerating both (as we have already done in this thread and
several prior), I'm not sure what is left for the community to discuss
here. Final evaluation of the benefits and drawbacks can be left to the
internal team responsible for shepherding the community.


> So there are clear benefits associated with a switch, whereas the
> disadvantages are more or less hypothetical and might as well be proven
> wrong by reality.
> If such vague fear is enough to entrench the status quo, I'd really worry
> about the impact of this mindset on future progress.
>
> Telegraph and morse code are much more mature than even email, and more
> reliable than this whole internet-thing, and there are marked pieces of
> clay that exist for thousands of years and might still be readable when all
> our modern digital data is forgotten, so progress is definitely not always
> improvement in every aspect.
> But to repeat it once more: In this case, moving to a more modern solution
> keeps the old one intact.
>
> - Tino
>
> I agree with email is and Swift is young. Not sure that's a real reason to
> ditch email, however 😀. In fact, I could say *because* email is so old,
> everything about it has become mature and reliable. Besides great,
> customized clients, it's also a lower requirement for participants.
>
> The reason for the original statement is that I see many similarities to
> Objective-C:
> I know several people who oppose Swift very strongly, although the mature
> and reliable Objective-C with its customised compilers and lower
> requirements happily coexists with its successor.
>
> ___
> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

Gmail does the same; I wonder if it's a Mailman feature/bug that triggers
the splitting.
On Mon, Feb 6, 2017 at 7:59 PM Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> Oh, Mail messes up the grouping of them quite a lot in my experience.
> Whenever we get one of those epic, super controversial threads with tons of
> posts in them, it’s almost guaranteed to split into two or three parallel
> threads, on my machine anyway.
>
> Charles
>
> On Feb 6, 2017, at 6:45 PM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Mail.app grouped it in the correct thread (further proves that email
> clients are awesome 😀). Unfortunately mailman did not do so.
>
> 
>
> On Feb 6, 2017, at 4:40 PM, James Berry  wrote:
>
>
> On Feb 6, 2017, at 4:28 PM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve been wondering about this for a while. What heuristic does mailman
> use to group emails? It this really impossible even if the title, email
> body, recipient all fits as if it’s from a existing subscriber?
>
>
> This email is related to the thread only by the subject. How does it work
> in your email client? I just wrote a new message, no “reply to”, etc.
>
>
> On Feb 6, 2017, at 4:12 PM, Xiaodi Wu  wrote:
>
> No, as you define it, they're not mutually exclusive. But maintaining the
> option to reply to a thread at an indeterminate point in the future when
> you finally get around to reading _is_ essentially mutually exclusive to
> not storing a copy of every email sent to the mailing list on your email
> account somewhere.
>
>
>
>
> ___
> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

On Thu, Feb 2, 2017 at 6:37 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It's at least worth a beta test.
>>
>>
>> There are real concerns to work out here — just moving to the forum
>> blindly would be bad if it is highly disruptive to the community having
>> important discussions.  I DO think a forum is likely the way to go, but I
>> also am not dismissive that individuals who are highly active on
>> swift-evolution that prefer an email workflow will not have their own
>> participation significantly compromised by just moving to a forum in a
>> cavalier way.
>>
>> What I have enjoyed seeing from this thread is a healthy discussion about
>> tradeoffs of both approaches and an identification of concerns of moving
>> away from the mailing lists.  Some responses to those concerns have been
>> "Discourse can handle that", which to me is part of the evaluation of the
>> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup
>> so we *could* evaluate thing like the email bridge.  For example,
>> experimenting of whether or not a rich HTML email works versus plain text
>> emails for inline responses (which turns out to have problems), etc.
>> That's all super useful for actually evaluating moving to Discourse, so in
>> my mind we are actually trying things out and identifying problem points.
>>
>> The other thing I'm considering is the practical logistics of getting
>> this set up and maintained (from an infrastructure perspective).  That's
>> not something that needs to be discussed on this thread — I'd rather the
>> thread focus on whether a forum is the right thing for the community.  But
>> it is still something that is being considered in tandem to this
>> discussion, which obviously needs to be figured out before we just jump to
>> using Discourse (if that is what we end up doing).
>>
>
> On the topic of whether a forum is the right thing for the community, I
> figure I should throw another point into the conversation. Forums are often
> designed around a rewards system to encourage participation in approved
> ways, and to encourage it frequently. People who write popular posts get
> more likes, or stars, or dingbats, and voting is encouraged from the
> community to surface the most liked/starred/dingbatted. Just earlier in
> this thread, there were explicit calls for any adopted platform to have
> liking/unliking features.
>
> In a mailing list format, everyone is free to start a new thread. Whether
> you invented the language or started learning it yesterday, if you have a
> new idea, it comes into everyone's inbox in exactly the same way. No one's
> user name has extra flares or trophies or whatever reminding you of their
> status. Yes, it's true that there have been a proliferation of +1's lately.
> It is also true that not too long ago community members reminded each other
> not to do that. The mantra, if I recall, was that it wasn't about
> soliciting upvotes or downvotes, but rather about posting thoughtful
> critiques, new takes on the the idea, alternative designs, etc.
>
> So I guess I'd sum up the point as this: in the current setup, everyone's
> message is treated equally (unless it exceeds the max email size limit,
> ugh); in a forum, everyone's likes are treated equally. Are we unsatisfied
> with the current community ethos? Do we want the evolution process to be
> about what ideas garnered the most votes and whose thoughts are most
> popular?
>

FWIW, I think this point is moot when it comes to Discourse — the max
allowed "likes" per day is adjustable, which I believe includes turning it
to 0 / off. If it's determined to be harmful to "community ethos" the
admins would be free to disable it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] for-else syntax

[Jacob Bandes-Storch via swift-evolution]

One possible con: this is subtly but extremely different from Python, where
a for loop's else clause is executed only if there was no `break` from the
loop.
On Wed, Feb 1, 2017 at 8:48 AM Chris Davis via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi,
>
> Often when I’m programming I stumble upon this scenario:
>
> I have a list of items that may or may not be empty - if it’s full, I do
> one thing, if it’s empty I do something else, my code looks like this:
>
> class Example_1
> {
> let names = ["Chris", "John", "Jordan"]
>
>
> /// Loop over names, if no names, print no names
> func run()
> {
> for name in names
> {
> print(name)
> }
>
>
> if names.count == 0
> {
> print("no names")
> }
> }
> }
>
> let exampleOne = Example_1()
> exampleOne.run()
>
> However, Personally, I would find it more pleasing to write something like
> this:
>
> class Example_2_Proposed
> {
> let names:[String] = []
>
>
> /// Loop over names, if no names, print no names
> func run()
> {
> for name in names
> {
> print(name)
> } else {
> print("no names")
> }
> }
> }
>
> let exampleTwo = Example_2_Proposed()
> exampleTwo.run()
>
> The difference here is a “for-else” type syntax where if there were no
> items in the array it would simply fall through to the else statement.
>
> What would be the pros/cons of introducing such syntax?
>
> Is there’s a way of doing something similar in swift already?
>
> Thanks
>
> Chris
>
>
>
>
> ___
> 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] protocol-oriented integers (take 2)

[Jacob Bandes-Storch via swift-evolution]

Cute. Reminds me of C++ STL's struct tags: http://en.cppreference.
com/w/cpp/utility/piecewise_construct_t
http://en.cppreference.com/w/cpp/iterator/iterator_tags

On Tue, Jan 31, 2017 at 12:53 PM, Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Brent,
>
> Thanks a lot for your suggestions! After having discussed them with Dave,
> we came up with the following design that I personally like a lot.
>
> enum Overflowing { case .withOverflow }
> enum FullWidth { case .fullWidth }
>
> protocol FixedWidthInteger {
>   func adding(_ other: Self, _: Overflowing) -> (partialValue: Self,
> overflow: ArithmeticOverflow)
>   func subtracting(_ other: Self, _: Overflowing) -> (partialValue: Self,
> overflow: ArithmeticOverflow)
>   func multiplied(by other: Self, _: Overflowing) -> (partialValue: Self,
> overflow: ArithmeticOverflow)
>   func divided(by other: Self, _: Overflowing) -> (partialValue: Self,
> overflow: ArithmeticOverflow)
>
>   func multiplied(by other: Self, _: FullWidth) -> DoubleWidth
>   func dividing(_ other: DoubleWidth, _: FullWidth) -> (quotient:
> Self, remainder: Self)
> }
>
>
> Call sites would look like:
>
> x.multiplied(by: y, .withOverflow) and x.multiplied(by: y, .fullWidth)
>
> a little different for the division:
>
> x.divided(by: y, .withOverflow) and y.dividing(x, .fullWidth)
>
> Note the inverse-ness of `dividing`, but the lack of the argument label
> makes it quite natural.
>
>
> > 2. There is no quotient-and-remainder-with-overflow, either regular or
> double-width. Can we do that?
> What will the partialValue equivalent be in case of overflow in
> overflowing quotient+remainder division?
> >
> > 3. "Overflow" is not really a good description of what's happening in
> division; the value is undefined, not overflowing. Is there a better way to
> express this?
> Division by 0 is not overflowing, true, but Int.min / (-1) is.
> >
> > 4. For that matter, even non-fixed-width division can "overflow"; should
> that concept be hoisted higher up the protocol hierarchy?
> In my head, overflow is a notion related to fixed sized types. You simply
> don’t have enough room to represent certain values. Following this line of
> thought, binary integer is not bounded, and can grow at will. So
> FixedWidthInteger looks like the right place for overflowing operations.
> And if we decide to not consider division by 0 an overflow, the model seems
> quite consistent.
>
>
> > On Jan 30, 2017, at 7:55 PM, Brent Royal-Gordon 
> wrote:
> >
> >> On Jan 30, 2017, at 11:31 AM, Max Moiseev  wrote:
> >>
> >> doubleWidthDivide should not return a DoubleWidth for two reasons:
> >> 1. The components of it’s return type are not high and low, but are
> quotient and remainder instead.
> >> 2. In DoubleWidth high is T and low is T.Magnitude, which is not the
> case for quotient and remainder.
> >
> > You're right about the return value; for `doubleWidthDivide(_:_:)`, I
> was thinking about changing the dividend. Specifically, I'm thinking we
> should change these to:
> >
> >   static func doubleWidthMultiply(_ lhs: Self, _ rhs: Self) ->
> DoubleWidth
> >   static func doubleWidthDivide(_ lhs: DoubleWidth, _ rhs:
> Self) -> (quotient: Self, remainder: Self)
> >
> > I'm also thinking a little bit about spelling of these operations. I'd
> *love* to be able to call them `*` and `/` and let the type system sort
> things out, but that would cause problems, especially for multiply (since
> the return value is the only thing different from a normal `*`). We could
> invent a new operator, but that would be a bit much. Could these be simply
> `multiply` and `divide`, and we'll permit the `DoubleWidth`
> parameter/return type to explain itself?
> >
> > I'm also thinking the second parameter should be labeled `by`, since
> that's the way people talk about these operations. Applying both of these
> suggestions, we'd get:
> >
> >   static func multiply(_ lhs: Self, by rhs: Self) ->
> DoubleWidth
> >   static func divide(_ lhs: DoubleWidth, by rhs: Self) ->
> (quotient: Self, remainder: Self)
> >
> >   let x = Int.multiply(a, by: b)
> >   let (aʹ, r) = Int.divide(x, by: b)
> >   assert(a == aʹ)
> >   assert(r == 0)
> >
> > Should the standard library provide extensions automatic definitions of
> multiplication and division in terms of their double-width equivalents?
> >
> >   extension FixedWidthInteger {
> >   func multipliedWithOverflow(by other: Self) ->
> (partialValue: Self, overflow: ArithmeticOverflow) {
> >   let doubledResult = Self.multiply(self, by: other)
> >   let overflowed = doubledResult.high !=
> (doubledResult < 0 ? -1 : 0)
> >   return (Self(bitPattern:
> doubledResult.lowerValue), overflowed ? .overflowed : .none)
> >   }
> >
> >   func quotientAndRemainder(dividingBy other: Self) ->
> (quotient: Self, remainder: Self) {
> >   precondition(o

Re: [swift-evolution] Removing enumerated?

[Jacob Bandes-Storch via swift-evolution]

I'm still a fan of that indexed() proposal...
On Tue, Jan 31, 2017 at 8:52 AM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 31, 2017, at 10:46 AM, Chris Eidhof  wrote:
>
> I agree that it's very useful. I use it regularly. The documentation isn't
> that unclear, imo. To me, the underlying problem isn't enumerated. I think
> the underlying cause is that collections aren't indexed with zero based
> indices.if you don't understand this (which is the case for many
> experienced programmers new to Swift) it's hard to understand, and (too)
> easy to make a mistake.
>
>
> This indicates that the underlying problem is *not* enumerated at all.
> The underlying problem is that Swift is still a relatively new language and
> it does some things differently than other languages (for very good
> reasons).
>
> You’re making a great case for the need to continue spreading knowledge
> about Swift’s collection model through the community.
>
> I don’t think it’s problematic for an experienced programmer who is new to
> the language to bump up against this when the reach for `enumerated`.
> They’re going to need to learn the collection model sooner or later.
>
>
> On Tue, 31 Jan 2017 at 17:41, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 31, 2017, at 10:36 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I totally sympathize with users being confused. It's an interesting idea
> to move it to Array only.
>
> The thing is, it does make sense (and wouldn't be confusing) to enumerate
> a dictionary or set. Moreover, the behavior is _exactly_ what it says on
> the tin: when you enumerate something in real life, there is no sense in
> which the number is related to some sort of index. Can we fix this by
> documentation? Like, a big blaring "don't use this when you want the index”?
>
>
> +1.  A similar method on collection that provides indices might be useful
> but that doesn’t mean we should remove `enumerated`.  User confusion should
> be addressed by documentation.
>
> On Tue, Jan 31, 2017 at 09:35 Ole Begemann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 31/01/2017 16:19, Ole Begemann via swift-evolution wrote:
> > Here are three previous discussion about this topic:
> >
> > 1) December 2015: [Idea] Add an (Index,Element) sequence to
> > CollectionType
> >
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004561.html
> > and
> >
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004626.html
> >
> >
> > 2) April 2016: [Idea] Replace enumerate() with something more explicit
> >
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015074.html
> >
> >
> > 3) September 2016: [Proposal draft] Introducing `indexed()`
> collections
> >
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027355.html
>
> To clarify, the discussions I linked to don't all propose to remove or
> replace `enumerated()`, but they all talk about the potential confusion
> about what `enumerated()` does and does not do.
>
> ___
> 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
>
> --
> Sent from my phone
>
> ___
> 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] Why doesn't Swift allow a variable and a function with the same name?

[Jacob Bandes-Storch via swift-evolution]

You said "The ability to reference a function by only the first segment of
its name is likewise legacy of the original model..." — how else could you
refer to a nullary function? Even if labels were required for naming
(>0)-ary functions, there's still ambiguity between a nullary function and
a variable.
On Mon, Jan 30, 2017 at 7:54 PM Joe Groff  wrote:

>
> > On Jan 30, 2017, at 7:34 PM, Jacob Bandes-Storch 
> wrote:
> >
> > Although there's no spelling for this...
> https://bugs.swift.org/browse/SR-3550
>
> IMO, the way to spell `foo` with no arguments is just `foo`. If we
> strictly required the labels for referring to n-ary functions, that would
> make it unambiguous…
>
> -Joe
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Jacob Bandes-Storch via swift-evolution]

Although there's no spelling for this...
https://bugs.swift.org/browse/SR-3550
On Mon, Jan 30, 2017 at 7:29 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 30, 2017, at 11:42 AM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > The reason Swift works like this is because you can assign a function
> value (independently of calling it) to a variable. So there aren't two
> separate namespaces separating function names and variable names.
>
> To be honest, I would say that there's no "reason" for this, except as
> lingering effects of our early "functions have simple names, and arguments
> have labeled tuple type" model. If we had originally implemented the
> language with its current (at least aspirational) Smalltalk-ish
> compound-names model, we probably would have ended up allowing this, since
> the var and func do formally have different names. The ability to reference
> a function by only the first segment of its name is likewise legacy of the
> original model, though it happens to be useful since good naming hygiene
> encourages different base names for different things to begin with.
>
> -Joe
> ___
> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

Plus (heart), but not minus. Although it looks like someone has written a
plugin for this:
https://meta.discourse.org/t/retort-a-reaction-style-plugin-for-discourse/35903

On Mon, Jan 30, 2017 at 5:35 PM, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> Does Discourse allow stuff to be "plus-one-ed"? I like how Reddit has this
> feature and I notice that many people on this mailing list either -1 or +1
> something.
>
> I feel like it is very democratic.
>
> On Mon, Jan 30, 2017 at 10:52 AM Rudolf Adamkovič via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> +1 for either e-mail or GitHub issues. No need for yet another tool...
>>
>> R+
>>
>> On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I'm surprised there is so little support for JIRA. Anyone think it's a
>> bad tool for the job?
>> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via
>> swift-evolution  wrote:
>>
>> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I haven't yet seen a good answer to the question: who is going to put in
>> the long-term commitment to host and maintain a replacement solution,
>> moderate forums, make technical upgrades and backups, and perform all the
>> other maintenance and administrative work it takes to properly run a system
>> like Discourse, a web forum, or even a bug tracker.
>>
>>
>> I will volunteer to be a moderator of the Swift forums. I have time
>> available, and the core team surely has better things to do.
>>
>> Nevin
>> ___
>> 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
>>
>>
>> Personally, I’d prefer if we used GitHub Issues. I like keeping the
>> current state of the project together with the known issues in it. It also
>> has better formatting and actually supports some kind of syntax
>> highlighting for Swift code.
>>
>> I just assumed that some of our requirements (e.g. syncing with Apple’s
>> internal “radar” system) disqualified it.
>>
>> The reason why we don’t have topics every month about migrating our
>> bug-tracking system is that JIRA (while perhaps not optimal) is at least
>> passable. That’s more than you can say for the mailing lists, most of the
>> time.
>>
>> - Karl
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Jacob Bandes-Storch via swift-evolution]

Suppose it were allowed. What should this do?

let something = randomArray

On Mon, Jan 30, 2017 at 11:37 AM, Michael Gubik via swift-evolution <
swift-evolution@swift.org> wrote:

> Example that does not compile:
>
> let randomArray = randomArray(withCapacity: 4096)
>
> Compiler error: “Variable used within its own initial value”
> The variable name unfortunately clashes with the function name.
>
> This problem forces the developer to think about an alternative name.
> IMHO that’s suboptimal since many times the most canonical naming would be
> one where these two go by the same name.
>
> It’s not a big problem in practice but I wonder if there are plans to
> change this?
>
>
> Thanks,
> Michael Gubik
>
> ___
> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

UX:

*---EmailJIRADiscourse>

😉

On Thu, Jan 26, 2017 at 5:10 PM, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm surprised there is so little support for JIRA. Anyone think it's a bad
> tool for the job?
> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via
> swift-evolution  wrote:
>
>> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I haven't yet seen a good answer to the question: who is going to put in
>> the long-term commitment to host and maintain a replacement solution,
>> moderate forums, make technical upgrades and backups, and perform all the
>> other maintenance and administrative work it takes to properly run a system
>> like Discourse, a web forum, or even a bug tracker.
>>
>>
>> I will volunteer to be a moderator of the Swift forums. I have time
>> available, and the core team surely has better things to do.
>>
>> Nevin
>> ___
>> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

On Thu, Jan 26, 2017 at 12:43 PM, James Berry via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Since many will likely want to continue to access the discussion via mail,
> I have some questions for anybody who actually has real-life experience in
> using Discourse primarily via email:
>
> 1. Can one sign up to receive all posts within a project via email? Or
> does one need to sign up for email on a thread-by-thread basis?
>

Yes, it's called "mailing list mode". Looks like this:
http://discourse.natecook.com/t/pitch-replace-discourse-with-a-mailing-list/3052/3?u=jtbandes


> 2. Can one receive email notifications of new threads?
>

Mailing list mode enables this.


> 3. How does one create a new thread via email? (presumably just by sending
> an email with a new subject, ala mailing list?)
>

Yep, here's an example: http://discourse.natecook.com/
t/an-evaluation-of-mailing-list-mode/3053/1


>
> Based on my (limited, non-subscriber-to-discourse) experience so far, I
> would vote for the status quo, perhaps based on years of using mailing
> lists via email. But I’m trying to be open minded.
>
> James
>
> ___
> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

I took some screenshots of this:

http://discourse.natecook.com/t/pitch-replace-discourse-with-a-mailing-list/3052/3

We can do some further testing once we set up inbound email support.

On Thu, Jan 26, 2017 at 11:58 AM David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Awesome! I want to use this now :D Btw, for the people who prefer email:
> how would a system where discourse sends them the email work for them?
>
> On 26 Jan 2017, at 19:02, Nate Cook via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 25, 2017, at 3:32 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have no problem with the project moving to forums instead of the Mailman
> mailing lists we have now — if it is the right set of tradeoffs.
>
> My preference is to approach the topic objectively, working from goals and
> seeing how the mailing lists are aligning with those goals and how an
> alternative, such as Discourse, might do a better job.
>
> The current use of mailing lists has been carry-over of how both LLVM does
> public discussion (which is all mailing lists) and how the Swift team at
> Apple has used mailing lists for discussion.  That inertia has benefits in
> that it is a familiar workflow that is “proven” to work — but the doesn’t
> mean it is the best option going forward.
>
> Here are some of the things that matter to me:
>
> - Topics are easy to manage and search, with stable URLs for archives.
>
> - It is easy to reference other topics with a stable (canonical) URL that
> allows you to jump into that other topic easily.  That’s hard to do if you
> haven’t already been subscribed to the list.
>
> - Works fine with email clients, for those who want to keep that workflow
> (again this inertia is important).
>
> - Code formatting, and other tools that add clarity in communication, are
> a huge plus.
>
> I’d like to understand more the subjective comments on this thread, such
> as "may intimidate newcomers”.  This feels very subjective, and while I am
> not disagreeing with that statement I don’t fully understand its
> justification.  Signing up for mailing lists is fairly straightforward, and
> one isn’t obligated to respond to threads.  Are forums really any less
> “intimating”? If so, why is that the case?  Is this simply a statement
> about mailing lists not being in vogue?
>
> I do also think the asynchronous nature of the mailing lists is important,
> as opposed to discussions feeling like a live chat.  Live chat, such as the
> use of Slack the SwiftPM folks have been using, is very useful too, but I
> don’t want participants on swift-evolution or any of our mailing lists feel
> obligated to respond in real time — that’s simply not the nature of the
> communication on the lists.
>
> So in short, using mailing lists specifically is not sacred — we can
> change what we use for our community discussions.  I just want an objective
> evaluation of the needs the mailing lists are meant to serve, and work from
> there.  If moving to something like (say) Discourse would be a negative on
> a critical piece that is well-served by the mailing lists, that would (in
> my opinion) a bad direction to take.  I’m not saying that is the case, just
> that this is how I prefer we approach the discussion.
>
>
> I’ve looked into Discourse a bit, and it does look very promising. One
> *specific* way in which a motivated individual could help would be to take
> a look at Discourse’s import scripts
>  and
> try importing swift-evolution’s mailing archives with them. We absolutely
> do not want to lose history when we switch technologies. Do the messages
> import well? Are threading and topics maintained in a reasonable manner?
> Does Discourse provide effective UI for looking into past discussions on
> some specific topic we’re interested in?
>
> - Doug
>
>
> ✋
>
> I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem
> dependencies, and sed-cleaned mbox files to try this out—you can see the
> results of an import (using one or two day old data) at this address:
> http://discourse.natecook.com/
>
> It looks like the threads were handled properly, though they bear some
> obvious marks of their mailing list origins. Users can actually claim their
> accounts if they do a password reset. However:
> - it's hooked up to a trial SendGrid account, which will top out at 100
> emails/day
> - I should probably delete this soon so Google doesn't think it's the real
> deal
>
> I might have mentioned this before, but I'm strongly in favor of
> forum-based solution over the mailing list (at least for this group), and
> Discourse seems to be the best one running right now (and fairly open to
> extension and customization). I made a new topic here to demonstrate a
> couple features (code blocks and inli

Re: [swift-evolution] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

Not true if you quote something via the web interface. See my quote here:
http://discourse.natecook.com/t/pitch-add-dark-mode-to-swift/3051


On Thu, Jan 26, 2017 at 12:03 PM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Thu Jan 26 2017, Nate Cook  wrote:
>
> > ✋
> >
> > I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem
> > dependencies, and sed-cleaned mbox files to try this out—you can see
> > the results of an import (using one or two day old data) at this
> > address:
> >   http://discourse.natecook.com/
> >
> > It looks like the threads were handled properly, though they bear some
> > obvious marks of their mailing list origins. Users can actually claim
> > their accounts if they do a password reset. However:
> >   - it's hooked up to a trial SendGrid account, which will top out
> at 100 emails/day
> >   - I should probably delete this soon so Google doesn't think it's
> the real deal
>
> It's a shame that it has no facility for hiding long quotations.  Trying
> to find the actual content in this thread is pretty awful:
> http://discourse.natecook.com/t/strings-in-swift-4/2980/13
>
> Once upon a time, there was a tradition of carefully crafting the
> presentation of replies to mailing lists
>  but I fear those
> days may be behind us.
>
> > I might have mentioned this before, but I'm strongly in favor of
> > forum-based solution over the mailing list (at least for this group),
> > and Discourse seems to be the best one running right now (and fairly
> > open to extension and customization). I made a new topic here to
> > demonstrate a couple features (code blocks and inline images):
> >   http://discourse.natecook.com/t/pitch-add-dark-mode-to-swift/3051
>
> That said, I too am strongly in favor of moving to Discourse.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

Discourse provides:

- Reply to a topic via email:
https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099
- "Mailing list mode":
https://discourse.mcneel.com/t/mailing-list-mode-for-discourse/5763 &
https://meta.discourse.org/t/what-is-mailing-list-mode/46008

On Wed, Jan 25, 2017 at 10:13 PM, Ted kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

> I had this same question in my mind — especially if one can reply to an
> email and it posts back to the forum.
>
> The mailing list model works well for those who want to get the entire
> feed of traffic, and easily monitor which threads they want to follow/read
> using the standard affordances in their mail program (e.g., mail filters,
> flagging messages, and so on).
>
> The forum interface provides a way for people to just jump in and
> participate on specific topics, provide better (standard) rendering of
> content — such as code (which can be nice for technical conversations), and
> better archiving and possibly be more searchable.
>
> If Discourse supports participation via email, it seems we get the best of
> both worlds, as you say.  I'm not super familiar with what Discourse can do
> in this regards.
>
> On Jan 25, 2017, at 9:22 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Can a forum be configured to send each new post to the mailing list with
> proper subject line?
>
> If so, that would enable a best-of-both-worlds scenario—or at least the
> ability to dip our toes in a forum to see if it works, while still showing
> everything on-list.
>
> Nevin
>
>
>
> On Wed, Jan 25, 2017 at 11:28 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 25, 2017, at 6:57 PM, Xiaodi Wu  wrote:
>>
>> Signing up for mailing lists is straightforward, yes—but that’s only a
>>> small part of it. Signing up for a mailing list is a *commitment.* Once you
>>> do it, your inbox will be inundated with mailing list posts, making it
>>> difficult to find messages that actually have been intended for you
>>> personally. Therefore, you’ll have to deal with that somehow. You can set
>>> up rules in Mail to route mailing list posts to a separate folder, but that
>>> won’t help you if you access your webmail from a public machine.
>>>
>>>
>>> FWIW, I subscribe to many mailing lists in gmail and have it auto filter
>>> emails to mailing lists into a separate mailbox (well, really, tags) for
>>> each list.  It works great for me.
>>>
>>> This doesn’t detract from your point about it being a commitment though.
>>>
>>
>> It does kind of imply a follow-up question, though: is it _undesirable_
>> that signing up for a mailing list is a modicum of commitment?
>>
>>
>> I’m mixed on that.  On the one hand, it is great to have some level of
>> commitment before people inject their opinion into the mix for some
>> discussion.  OTOH, I’m sympathetic to the desire that a lot of people want
>> to just “follow along” without participating, and the mailman web interface
>> is pretty uninspired.
>>
>> -Chris
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

...never mind, figured out how to download it —
https://meta.discourse.org/t/import-mailman-archives-into-discourse/18537/11

On Wed, Jan 25, 2017 at 9:53 PM, Jacob Bandes-Storch 
wrote:

> On Wed, Jan 25, 2017 at 1:32 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I have no problem with the project moving to forums instead of the
>> Mailman mailing lists we have now — if it is the right set of tradeoffs.
>>
>> My preference is to approach the topic objectively, working from goals
>> and seeing how the mailing lists are aligning with those goals and how an
>> alternative, such as Discourse, might do a better job.
>>
>> The current use of mailing lists has been carry-over of how both LLVM
>> does public discussion (which is all mailing lists) and how the Swift team
>> at Apple has used mailing lists for discussion.  That inertia has benefits
>> in that it is a familiar workflow that is “proven” to work — but the
>> doesn’t mean it is the best option going forward.
>>
>> Here are some of the things that matter to me:
>>
>> - Topics are easy to manage and search, with stable URLs for archives.
>>
>> - It is easy to reference other topics with a stable (canonical) URL that
>> allows you to jump into that other topic easily.  That’s hard to do if you
>> haven’t already been subscribed to the list.
>>
>> - Works fine with email clients, for those who want to keep that workflow
>> (again this inertia is important).
>>
>> - Code formatting, and other tools that add clarity in communication, are
>> a huge plus.
>>
>> I’d like to understand more the subjective comments on this thread, such
>> as "may intimidate newcomers”.  This feels very subjective, and while I am
>> not disagreeing with that statement I don’t fully understand its
>> justification.  Signing up for mailing lists is fairly straightforward, and
>> one isn’t obligated to respond to threads.  Are forums really any less
>> “intimating”? If so, why is that the case?  Is this simply a statement
>> about mailing lists not being in vogue?
>>
>> I do also think the asynchronous nature of the mailing lists is
>> important, as opposed to discussions feeling like a live chat.  Live chat,
>> such as the use of Slack the SwiftPM folks have been using, is very useful
>> too, but I don’t want participants on swift-evolution or any of our mailing
>> lists feel obligated to respond in real time — that’s simply not the nature
>> of the communication on the lists.
>>
>> So in short, using mailing lists specifically is not sacred — we can
>> change what we use for our community discussions.  I just want an objective
>> evaluation of the needs the mailing lists are meant to serve, and work from
>> there.  If moving to something like (say) Discourse would be a negative on
>> a critical piece that is well-served by the mailing lists, that would (in
>> my opinion) a bad direction to take.  I’m not saying that is the case, just
>> that this is how I prefer we approach the discussion.
>>
>>
>> I’ve looked into Discourse a bit, and it does look very promising. One
>> *specific* way in which a motivated individual could help would be to take
>> a look at Discourse’s import scripts
>>  
>> and
>> try importing swift-evolution’s mailing archives with them. We absolutely
>> do not want to lose history when we switch technologies. Do the messages
>> import well? Are threading and topics maintained in a reasonable manner?
>> Does Discourse provide effective UI for looking into past discussions on
>> some specific topic we’re interested in?
>>
>> - Doug
>>
>
> I'd be willing to put some time into trying this. But the relevant import
> script is for mbox files
> .
> Is it possible to publicly share the data files from the swift-evolution
> mailman installation, so someone can try importing them?
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jan 25, 2017 at 1:32 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have no problem with the project moving to forums instead of the Mailman
> mailing lists we have now — if it is the right set of tradeoffs.
>
> My preference is to approach the topic objectively, working from goals and
> seeing how the mailing lists are aligning with those goals and how an
> alternative, such as Discourse, might do a better job.
>
> The current use of mailing lists has been carry-over of how both LLVM does
> public discussion (which is all mailing lists) and how the Swift team at
> Apple has used mailing lists for discussion.  That inertia has benefits in
> that it is a familiar workflow that is “proven” to work — but the doesn’t
> mean it is the best option going forward.
>
> Here are some of the things that matter to me:
>
> - Topics are easy to manage and search, with stable URLs for archives.
>
> - It is easy to reference other topics with a stable (canonical) URL that
> allows you to jump into that other topic easily.  That’s hard to do if you
> haven’t already been subscribed to the list.
>
> - Works fine with email clients, for those who want to keep that workflow
> (again this inertia is important).
>
> - Code formatting, and other tools that add clarity in communication, are
> a huge plus.
>
> I’d like to understand more the subjective comments on this thread, such
> as "may intimidate newcomers”.  This feels very subjective, and while I am
> not disagreeing with that statement I don’t fully understand its
> justification.  Signing up for mailing lists is fairly straightforward, and
> one isn’t obligated to respond to threads.  Are forums really any less
> “intimating”? If so, why is that the case?  Is this simply a statement
> about mailing lists not being in vogue?
>
> I do also think the asynchronous nature of the mailing lists is important,
> as opposed to discussions feeling like a live chat.  Live chat, such as the
> use of Slack the SwiftPM folks have been using, is very useful too, but I
> don’t want participants on swift-evolution or any of our mailing lists feel
> obligated to respond in real time — that’s simply not the nature of the
> communication on the lists.
>
> So in short, using mailing lists specifically is not sacred — we can
> change what we use for our community discussions.  I just want an objective
> evaluation of the needs the mailing lists are meant to serve, and work from
> there.  If moving to something like (say) Discourse would be a negative on
> a critical piece that is well-served by the mailing lists, that would (in
> my opinion) a bad direction to take.  I’m not saying that is the case, just
> that this is how I prefer we approach the discussion.
>
>
> I’ve looked into Discourse a bit, and it does look very promising. One
> *specific* way in which a motivated individual could help would be to take
> a look at Discourse’s import scripts
>  and
> try importing swift-evolution’s mailing archives with them. We absolutely
> do not want to lose history when we switch technologies. Do the messages
> import well? Are threading and topics maintained in a reasonable manner?
> Does Discourse provide effective UI for looking into past discussions on
> some specific topic we’re interested in?
>
> - Doug
>

I'd be willing to put some time into trying this. But the relevant import
script is for mbox files
.
Is it possible to publicly share the data files from the swift-evolution
mailman installation, so someone can try importing them?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jan 25, 2017 at 12:05 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

> ...
>
> So in short, using mailing lists specifically is not sacred — we can
> change what we use for our community discussions.  I just want an objective
> evaluation of the needs the mailing lists are meant to serve, and work from
> there.  If moving to something like (say) Discourse would be a negative on
> a critical piece that is well-served by the mailing lists, that would (in
> my opinion) a bad direction to take.  I’m not saying that is the case, just
> that this is how I prefer we approach the discussion.
>

I'm interested in hearing more about the needs *you* feel the lists are
meant to serve. I'm guessing some of this is a strategic matter for the
Swift team, not something that all of us here on the list could fully
articulate.

The valuable things I see are:

- anyone with an idea can discuss it with the community, regardless of
their experience with PLs and compilers.
- multiple community members, and core team members, can collaborate in a
discussion or author a proposal.
- the community can watch and learn from discussion and implementation
processes amongst the core team.
- the core team can disseminate strategic vision and internal decisions
that otherwise would have to wait for the release notes or WWDC, or at
least a blog post.

None of these seem specific to any particular message board/system, except
that they are much more easily attainable with a highly asynchronous
system, like you mentioned.


>
> Ted
>
>
> On Jan 23, 2017, at 3:18 PM, Ole Begemann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Obligatory prior discussion sheds, er, I mean threads:
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo
> n-20151207/001537.html
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo
> n-20160725/025692.html
> / https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo
> n-20160801/thread.html#25765
>
>
> I haven't followed the previous discussions closely. As someone who mostly
> follows the discussions passively and only rarely posts something to the
> list, I have two major complaints with the current situation:
>
> * The disconnect between the messages in my mail client and their URLs in
> the list archive makes sharing or bookmarking messages a major pain in the
> ass. If it were possible for each message to contain its own permalink in
> the footer, I would be much happier. It seems this feature is available in
> Mailman 3 [1], but the Swift lists seem to be running on Mailman 2.x.
>
> * The web archive has very bad usability. I suppose design is a matter of
> taste, but having the archive organized by week is just wrong. This means
> that readers will regularly miss significant parts of threads that cross
> week boundaries without even noticing it.
>
> I don't like the mailing lists (and hadn't subscribed to any for close to
> a decade before Swift), but fixing the above two points would go 90% of the
> way for me.
>
> If you're counting votes, I'm also +1 for trying out Discourse.
>
> Another, less important complaint:
>
> * Readability is inconsistent because people use different formatting and
> email allows full control over HTML. I assume a forum that allows Markdown
> strikes the ideal middle ground between some control over formatting but
> not needlessly messing with font sizes etc.
>
> I can understand if the Swift team is hesitant to switch to a forum. If
> you have a working mailing list infrastructure everybody at the company is
> used to, migrating to a forum is a pretty big undertaking and potential
> disruption to the workflow. I'm not certain conversations will be much
> easier to follow in a forum.
>
> I found it very uncomfortable to read the mailing lists in my normal mail
> client because I want a totally different UI for the two tasks of reading
> swift-evolution vs. reading my regular mail. But this can be solved pretty
> easily by using a separate mail client only for the lists. I actually ended
> up reading the lists in Thunderbird via NNTP on news.gmane.org. Since
> Gmane is currently reorganizing and not adding new lists, this means I
> can't do this for new lists like swift-server-dev, but other than that it
> works well. The biggest downside is that I am limited to one device because
> read status isn’t synced across devices.
>
> [1]: https://mail.python.org/pipermail/mailman-users/2011-October
> /072379.html
> ___
> 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jan 25, 2017 at 8:28 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 25, 2017, at 6:57 PM, Xiaodi Wu  wrote:
>
> Signing up for mailing lists is straightforward, yes—but that’s only a
>> small part of it. Signing up for a mailing list is a *commitment.* Once you
>> do it, your inbox will be inundated with mailing list posts, making it
>> difficult to find messages that actually have been intended for you
>> personally. Therefore, you’ll have to deal with that somehow. You can set
>> up rules in Mail to route mailing list posts to a separate folder, but that
>> won’t help you if you access your webmail from a public machine.
>>
>>
>> FWIW, I subscribe to many mailing lists in gmail and have it auto filter
>> emails to mailing lists into a separate mailbox (well, really, tags) for
>> each list.  It works great for me.
>>
>> This doesn’t detract from your point about it being a commitment though.
>>
>
> It does kind of imply a follow-up question, though: is it _undesirable_
> that signing up for a mailing list is a modicum of commitment?
>
>
> I’m mixed on that.  On the one hand, it is great to have some level of
> commitment before people inject their opinion into the mix for some
> discussion.  OTOH, I’m sympathetic to the desire that a lot of people want
> to just “follow along” without participating, and the mailman web interface
> is pretty uninspired.
>

...not just uninspired, I'd go as far as saying it's hostile to discussion
— due to the way messages are (or aren't) organized in the pipermail
archive, it's often impossible to get a single link that encompasses the
entire discussion so far, so linking between threads is painful, not to
mention properly threading discussion in the first place. Quoting other
messages is left up to individual mail clients, which don't agree with each
other on formatting, and code blocks are similarly tragic.

On the other hand, I can link you directly to an individual post in a
231-message discussion thread about a Rust feature:
https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831/170
...glance through it for some great expandable inline quotes, syntax
highlighting, etc.

IMO, the only thing that makes the mailing list more of a "commitment" than
a forum is that the sign-up interface is harder to use, so it takes more
effort up front. Once you've signed up, it's not that much *extra* effort
to set up digests, or cancel your list membership, which might both be
viewed as "lower-commitment" options.


>
> -Chris
>
>
> ___
> 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] Optional Assignment Operator

[Jacob Bandes-Storch via swift-evolution]

If no uses are found (which I suspect will be the case), it becomes hard to
also find evidence of harm other than in contrived scenarios. Perhaps
contrived will be all we can find. Anyway, this is a bit off-topic for this
thread...
On Wed, Jan 25, 2017 at 11:24 AM John McCall  wrote:

> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu  wrote:
> Given lack of evidence of harm, is it really important to make such a
> source-breaking change?
>
>
> My first instinct is that, no, it's not important.  However, we haven't
> actually *tried* to find any evidence of harm, so it's a bit conclusory.
> If someone wants to make an evidence-based argument that it's harmful and
> that almost nobody is using it (intentionally/correctly), the balance could
> swing the other way.  That's for someone else to prove, though, since yes,
> at this point the bias has to be towards leaving things be.
>
> John.
>
>
> On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch 
> wrote:
>
> Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything
> other than "a = a ?? b".
>
> On another note, I don't see the value of "a? = b". I had never realized
> before that this works. Is this feature actually used in the wild? Should
> we consider removing it? (I could perhaps see some value if the assignment
> operator were overloadable, but it's not.)
>
>
> The core semantics (that ? on an l-value still produces an l-value) fall
> out from the ability to call a mutating method with a?.foo().  Once you
> have that, you have to decide what it means to put such an l-value to the
> left of an assignment operator, and we decided to make it Just Work™.  I
> agree that it is not a particularly useful operation in idiomatic Swift,
> especially with simple assignment (=), and we could consider just
> disallowing it.
>
> It also comes up with optional properties, I think, which is something we
> weren't always certain we were going to ban in native Swift (as opposed to
> imported ObjC code, where they're a fact of life).
>
> John.
>
>
> Jacob
>
> On Wed, Jan 25, 2017 at 10:28 AM, John McCall  wrote:
>
> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
> Really? My observation from a quick test is that "a? = b" assigns b to a
> if a already has a value, or does nothing if it's nil. This is sort of the
> opposite of what's being proposed, which is that "a ?= b" should assign to
> a only if it does NOT have a value.
>
>
> Right.  On the other hand, this does seem like a poor spelling for the
> operator, given the ease of confusion.
>
> Also, I'm finding it hard to imagine a use for this where the equivalent
> ?? invocation wouldn't be *much* clearer.  It just feels like you must be
> doing something backwards — "I've filled in a default value for this
> variable, now overwrite it if this other value exists".  Wouldn't the
> reverse generally be better?
>
> John.
>
> On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I’d like to propose a new operator for optional assignment in Swift.
> >
> > The idea is that by using this operator (e.g. by doing a ?= b), the
> optional on the right would be assigned to the variable on the left only
> when it has something to assign (i.e. when it's not nil).
>
> `a? = b` already does this. Maybe we need a fixit to make that more
> apparent, though.
>
> -Joe
>
> >
> > The implementation could be something as follows:
> >
> > /// Optional Assignment Operator
> > infix operator ?=: AssignmentPrecedence
> >
> > func ?=(left: inout T, right: T?) {
> > if right != nil {
> > left = right!
> > }
> > }
> >
> > func ?=(left: inout T?, right: T?) {
> > if right != nil {
> > left = right
> > }
> > }
> >
> > I hope you will consider adding this on a future release of this great
> programming language.
> >
> > Kind regards,
> > N. S.
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Assignment Operator

[Jacob Bandes-Storch via swift-evolution]

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything
other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized
before that this works. Is this feature actually used in the wild? Should
we consider removing it? (I could perhaps see some value if the assignment
operator were overloadable, but it's not.)

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall  wrote:

> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
> Really? My observation from a quick test is that "a? = b" assigns b to a
> if a already has a value, or does nothing if it's nil. This is sort of the
> opposite of what's being proposed, which is that "a ?= b" should assign to
> a only if it does NOT have a value.
>
>
> Right.  On the other hand, this does seem like a poor spelling for the
> operator, given the ease of confusion.
>
> Also, I'm finding it hard to imagine a use for this where the equivalent
> ?? invocation wouldn't be *much* clearer.  It just feels like you must be
> doing something backwards — "I've filled in a default value for this
> variable, now overwrite it if this other value exists".  Wouldn't the
> reverse generally be better?
>
> John.
>
> On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I’d like to propose a new operator for optional assignment in Swift.
>> >
>> > The idea is that by using this operator (e.g. by doing a ?= b), the
>> optional on the right would be assigned to the variable on the left only
>> when it has something to assign (i.e. when it's not nil).
>>
>> `a? = b` already does this. Maybe we need a fixit to make that more
>> apparent, though.
>>
>> -Joe
>>
>> >
>> > The implementation could be something as follows:
>> >
>> > /// Optional Assignment Operator
>> > infix operator ?=: AssignmentPrecedence
>> >
>> > func ?=(left: inout T, right: T?) {
>> > if right != nil {
>> > left = right!
>> > }
>> > }
>> >
>> > func ?=(left: inout T?, right: T?) {
>> > if right != nil {
>> > left = right
>> > }
>> > }
>> >
>> > I hope you will consider adding this on a future release of this great
>> programming language.
>> >
>> > Kind regards,
>> > N. S.
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Assignment Operator

[Jacob Bandes-Storch via swift-evolution]

Interesting, I think I misread it too. The one I was thinking of is the
same as the rejected proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md

Jacob

On Wed, Jan 25, 2017 at 10:11 AM, Joe Groff  wrote:

>
> > On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch 
> wrote:
> >
> > Really? My observation from a quick test is that "a? = b" assigns b to a
> if a already has a value, or does nothing if it's nil. This is sort of the
> opposite of what's being proposed, which is that "a ?= b" should assign to
> a only if it does NOT have a value.
>
>
> My mistake, I misread the proposal. What Nichi appears to be suggesting is
> an assignment that only happens when `b` has a value. I would hesitate to
> spell that `?=` since that's so similar to '? =', but perhaps it's useful,
> though there are many ways to spell that already.
>
> -Joe
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Assignment Operator

[Jacob Bandes-Storch via swift-evolution]

Really? My observation from a quick test is that "a? = b" assigns b to a if
a already has a value, or does nothing if it's nil. This is sort of the
opposite of what's being proposed, which is that "a ?= b" should assign to
a only if it does NOT have a value.
On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I’d like to propose a new operator for optional assignment in Swift.
> >
> > The idea is that by using this operator (e.g. by doing a ?= b), the
> optional on the right would be assigned to the variable on the left only
> when it has something to assign (i.e. when it's not nil).
>
> `a? = b` already does this. Maybe we need a fixit to make that more
> apparent, though.
>
> -Joe
>
> >
> > The implementation could be something as follows:
> >
> > /// Optional Assignment Operator
> > infix operator ?=: AssignmentPrecedence
> >
> > func ?=(left: inout T, right: T?) {
> > if right != nil {
> > left = right!
> > }
> > }
> >
> > func ?=(left: inout T?, right: T?) {
> > if right != nil {
> > left = right
> > }
> > }
> >
> > I hope you will consider adding this on a future release of this great
> programming language.
> >
> > Kind regards,
> > N. S.
> > ___
> > 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] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

Obligatory prior discussion sheds, er, I mean threads:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025692.html
/
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/thread.html#25765


On Mon, Jan 23, 2017 at 9:59 AM, Joshua Alvarado via swift-evolution <
swift-evolution@swift.org> wrote:

> It will be painted! ;)
>
> So far we have:
> +2 Disclosure
> +1 Slack
> +1 Issue tracker
>
> Let's really get everyone's opinions and see if we can get this rock
> rolling towards a better solution. Of course it will be Apple's choice in
> the end but we can give a voice on the matter to show we do care about
> moving over.
>
> Alvarado, Joshua
>
> On Jan 23, 2017, at 10:55 AM, David Waite 
> wrote:
>
> As long as we are pretending this bike shed is getting painted again…
>
> I would actually prefer something closer to an issue tracker than
> discourse. We get a lot of repeat and diverging topics, and it would be
> nice to mark discussions as related, duplicates, etc
>
> -DW
>
> On Jan 23, 2017, at 9:22 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1 for Discourse . Cannot wait any longer for
> this to happen.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 23. Januar 2017 um 17:18:42, Joshua Alvarado via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Hey swifters,
>   I would like to (re)open up discussion on moving away from email for the
> swift evolution mailing list. I know this has probably been discussed
> before but it really should be addressed again. I wouldn't even know how to
> find if it has been discussed before because it would be too hard to go
> back through the history.
>
> The main factors to move away from email is because email may deter
> newcomers, history, and threads. I may be speaking for myself when saying
> email may intimidate newcomers from expressing their opinions and thoughts.
> It is hard to know what has already been discussed and who is even in the
> active conversation. Keeping track of history is a pain as well. Searching
> through many emails to find who said what and when is not effective in
> email clients. Also, code formatting in emails is not effective. Let's
> discuss and actually make an action to move away from email if the
> community so agrees. Of course, recommendations are Slack, Hipchat (-1),
> and Gitter.
>
> --
> Joshua Alvarado
> alvaradojosh...@gmail.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 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] protocol-oriented integers (take 2)

[Jacob Bandes-Storch via swift-evolution]

On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> One example: earlier, it was demonstrated that a genetic lerp would not
> accommodate vector types. However, it _does_ work fine for any scalar (i.e.
> field) type; however, with the currently proposed integer protocols, one
> would constrain it to Arithmetic types, yet the algorithm would be bogus
> for integers.
>

I wouldn't say lerp is bogus (the results aren't wrong), just much
less useful.

On the other hand:

extension Collection where Iterator.Element: Arithmetic {
func mean() -> Iterator.Element {
return self.reduce(Iterator.Element(), +) /
Iterator.Element(count)  // assuming these initializers exist
}
}

Now [6, 7].mean() returns 6, and *that* I would call bogus.

Of course, there are some alternative ways to implement this which avoid
the issue:

- Implement it only for Iterator.Element: FloatingPoint.
- Implement it as mean() -> T, reducing by { $0 + T($1) }
or whatever the appropriate conversion initializer is, or simply converting
to floating point once *after* taking the sum.


>
> On Sun, Jan 15, 2017 at 19:21 Dave Abrahams  wrote:
>
>>
>>
>> on Sun Jan 15 2017, Xiaodi Wu  wrote:
>>
>>
>>
>> > On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution <
>>
>> > swift-evolution@swift.org> wrote:
>>
>> >
>>
>> >>
>>
>> >> on Sun Jan 15 2017, Xiaodi Wu  wrote:
>>
>> >>
>>
>> >> > There _may_ be value in recognizing the distinction between rings and
>>
>> >> > fields, perhaps? Just as the FP protocols make room for people to
>>
>> >> implement
>>
>> >> > their own decimal FP types, and just as you're trying to make
>> Arithmetic
>>
>> >> > accommodate complex numbers, the distinction would allow someone to
>> write
>>
>> >> > algorithms generic over rationals and reals (i.e. fields). Being
>> able to
>>
>> >> > represent exact fractions isn't so terribly niche, and I think the
>> design
>>
>> >> > wouldn't be terribly complicated by its accommodation:
>>
>> >> >
>>
>> >> > ```
>>
>> >> > // rename Arithmetic to Ring
>>
>> >> > // it's acceptable to omit `.one` from Ring, though some may call
>> that a
>>
>> >> > Pseudoring
>>
>> >> > // consider omitting division from Ring and pushing it down to
>>
>> >> > BinaryInteger and Field
>>
>> >> >
>>
>> >> > protocol BinaryInteger : Ring { ... }
>>
>> >> >
>>
>> >> > protocol Field : Ring {
>>
>> >> >   static var one { get }
>>
>> >> >   static func / (Self, Self) -> Self
>>
>> >> >   static func /= (inout Self, Self)
>>
>> >> >   var inverted: Self { get } // default impl: .one / self
>>
>> >> > }
>>
>> >> >
>>
>> >> > protocol FloatingPoint : Field { ... }
>>
>> >> > // rational number types and complex number types
>>
>> >> > // would also conform to Field
>>
>> >> > ```
>>
>> >>
>>
>> >> What generic algorithms would this enable?
>>
>> >
>>
>> > For one, anything to do with dividing into equal parts
>>
>>
>>
>> For example...?
>>
>>
>>
>> > could be generic over floating point, rational, and even complex
>>
>> > numbers, but you probably wouldn't want to include integer types in
>>
>> > such an algorithm.
>>
>> >
>>
>> >> Would they be appropriate
>>
>> >> for the standard library (as opposed to some more specialized numerics
>>
>> >> library)?
>>
>> >>
>>
>> >
>>
>> > The issue is that it's not terribly ergonomic to relegate `Field` to a
>>
>> > specialized library because one cannot retroactively conform
>>
>> > `FloatingPoint` to `Field`.
>>
>>
>>
>> I don't think this is an important enough concern to justify adding
>>
>> protocols to the standard library.  The number of types one has to
>>
>> individually make conform to Field is probably going to remain small.
>>
>>
>>
>> Show-me-the-mone^Walgorithms-ly y'rs,
>>
>>
>>
>> --
>>
>> -Dave
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] protocol-oriented integers (take 2)

[Jacob Bandes-Storch via swift-evolution]

On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu  wrote:

> On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> [ proposal link: https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f
>> 3fcc7cad8c ]
>>
>>
>> On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> Responding to both Jacob and Xiaodi here; thanks very much for your
>>> feedback!
>>>
>>> on Sat Jan 14 2017, Xiaodi Wu  wrote:
>>> > I think, in the end, it's the _name_ that could use improvement here.
>>> As
>>> > the doc comments say, `Arithmetic` is supposed to provide a "suitable
>>> basis
>>> > for arithmetic on scalars"--perhaps `ScalarArithmetic` might be more
>>> > appropriate? It would make it clear that `CGVector` is not meant to be
>>> a
>>> > conforming type.
>>>
>>> We want Arithmetic to be able to handle complex numbers.  Whether Scalar
>>> would be appropriate in that case sort of depends on what the implied
>>> field is, right?
>>>
>>
>> I think "scalar" is an appropriate term for any field. The scalar-ness
>> usually comes into play when it's used in a vector space, but using the
>> term alone doesn't bother me.
>>
>>
>>> It's true that CGPoint and CGVector have no obvious sensible
>>> interpretation of "42", and that's unfortunate.  The problem with
>>> protocols for algebraic structures is that there's an incredibly
>>> complicated lattice (see figures 3.1, 3.2 in
>>> ftp://jcmc.indiana.edu/pub/techreports/TR638.pdf) and we don't want to
>>> shove all of those protocols into the standard library (especially not
>>> prematurely) but each requirement you add to a more-coarsely aggregated
>>> protocol like Arithmetic will make it ineligible for representing some
>>> important type.
>>>
>>
>> Yep, it is quite complicated, and I understand not wanting to address all
>> that right now; calling it ScalarArithmetic seems appropriate to clarify
>> the limitations. FieldArithmetic might also be appropriate, but is less
>> clear (+ see below about quaternions).
>>
>> Daves Sweeris and Abrahams wrote:
>>
>> > > I was under the impression that complex numbers are scalar numbers...
>> although maybe not since once you get past, I think quaternions, you start
>> losing division and eventually multiplication, IIRC. (I hate it when two of
>> my recollections try to conflict with each other.)
>> >
>> > Well, you can view them as 2d vectors, so I'm not sure.  We need more
>> of a numerics expert than I am to weigh in here.
>>
>> But complex numbers have multiplication and division operations defined
>> (they form a field), unlike regular vectors in R². Meaning you can have a
>> vector space over the field of complex numbers.
>>
>> You still have multiplication and division past quaternions, but the
>> quaternions are *not commutative*. This isn't really a problem in Swift,
>> since the compiler never allows you to write an expression where the order
>> of arguments to an operator is ambiguous. This means they are *not a
>> field*, just a division ring
>> <https://en.wikipedia.org/wiki/Division_ring> (a field is a commutative
>> division ring). (I believe you can't technically have a vector space over a
>> non-commutative ring; the generalization would be a module
>> <https://en.wikipedia.org/wiki/Module_%28mathematics%29>. That's
>> probably an argument for the name ScalarArithmetic over FieldArithmetic.)
>>
>
> Hmm, the issue is that the integers are not a field. So, if we're going to
> have it all modeled by one protocol, maybe neither is the best term.
>

Eurgh. That's true. Appropriate mathematical terms go out the window when
"division" doesn't actually produce a multiplicative inverse.

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

Re: [swift-evolution] Pattern matching with Arrays

[Jacob Bandes-Storch via swift-evolution]

On Tue, Jan 3, 2017 at 10:10 AM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Dec 22, 2016, at 7:43 PM, Robert Widmann 
> wrote:
>
> Do you think there’s room for a more general Pattern Synonyms-like
>  feature that
> could extend this to things that look tuple-y?  We had a short conversation
> on Twitter 'round about the release of Swift 1.2 about Swiftz’s HList
>  
> implementation
> and my desire to be able to destructure them into tuples for native pattern
> matching.
>
>
> My personal favorite design for user-extensible pattern syntax is F#'s
> "active pattern" feature, which lets you declare a set of mutual exclusive,
> total or partial conditions along with a function body that computes which
> condition holds. For the specific case of container patterns, though, I
> feel like it's worth keeping a close association with Collection semantics,
> so that:
>
> - [] matches when the incoming collection's startIndex == endIndex,
> - [, ] fails if startIndex == endIndex, or else
> matches collection[startIndex] against  and recursively matches
> collection[startIndex.advancedBy(1)..]
> - [...] matches the remaining collection against 
>
> -Joe
>

This is really cool. I've never used F#, so thanks for pointing this out.
https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/
active-patterns  Extra points for the name (| "banana clips" |).

I've had something like this on my backburner-wishlist for a while.
Customizable patterns/bindings could be very powerful.

One use case I had in mind: writing parsers for binary formats such as
msgpack . For instance, msgpack encodes a
uint16 as 0xcd + high byte + low byte. If the 0xcd could be given as a
parameter to the "active pattern", you could imagine writing something like

match msgpackStream {  // a raw byte stream

// Scan 3 bytes, the first of which is equal to 0xcd.
// Theoretical syntax allowing a custom stream-scanner object to fill in
the two variable bindings
// by reading bytes from the stream. If the first byte were not 0xcd, the
match would fail.
case [0xcd, let hi, let lo]:
return UInt16(hi) << 8 | UInt16(lo)
...
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Generic Subscripts

[Jacob Bandes-Storch via swift-evolution]

On Sat, Jan 14, 2017 at 3:41 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Fri Jan 13 2017, John McCall  wrote:
>
> > I'm also not sure we'd ever want the element type to be inferred from
> > context like this.  Generic subscripts as I see it are about being
> > generic over *indexes*, not somehow about presenting a polymorphic
> > value.
>
> Actually I *would* want to be able to do that, though I admit it's the
> 1% case (or less).
>

1%? Wouldn't many JSON libraries, for instance, be eager to take advantage
of this?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] protocol-oriented integers (take 2)

[Jacob Bandes-Storch via swift-evolution]

[ proposal link: https://gist.github.com/moiseev/
62ffe3c91b66866fdebf6f3fcc7cad8c ]


On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Responding to both Jacob and Xiaodi here; thanks very much for your
> feedback!
>
> on Sat Jan 14 2017, Xiaodi Wu  wrote:
> > I think, in the end, it's the _name_ that could use improvement here. As
> > the doc comments say, `Arithmetic` is supposed to provide a "suitable
> basis
> > for arithmetic on scalars"--perhaps `ScalarArithmetic` might be more
> > appropriate? It would make it clear that `CGVector` is not meant to be a
> > conforming type.
>
> We want Arithmetic to be able to handle complex numbers.  Whether Scalar
> would be appropriate in that case sort of depends on what the implied
> field is, right?
>

I think "scalar" is an appropriate term for any field. The scalar-ness
usually comes into play when it's used in a vector space, but using the
term alone doesn't bother me.


> It's true that CGPoint and CGVector have no obvious sensible
> interpretation of "42", and that's unfortunate.  The problem with
> protocols for algebraic structures is that there's an incredibly
> complicated lattice (see figures 3.1, 3.2 in
> ftp://jcmc.indiana.edu/pub/techreports/TR638.pdf) and we don't want to
> shove all of those protocols into the standard library (especially not
> prematurely) but each requirement you add to a more-coarsely aggregated
> protocol like Arithmetic will make it ineligible for representing some
> important type.
>

Yep, it is quite complicated, and I understand not wanting to address all
that right now; calling it ScalarArithmetic seems appropriate to clarify
the limitations. FieldArithmetic might also be appropriate, but is less
clear (+ see below about quaternions).

Daves Sweeris and Abrahams wrote:

> > I was under the impression that complex numbers are scalar numbers...
although maybe not since once you get past, I think quaternions, you start
losing division and eventually multiplication, IIRC. (I hate it when two of
my recollections try to conflict with each other.)
>
> Well, you can view them as 2d vectors, so I'm not sure.  We need more of
a numerics expert than I am to weigh in here.

But complex numbers have multiplication and division operations defined
(they form a field), unlike regular vectors in R². Meaning you can have a
vector space over the field of complex numbers.

You still have multiplication and division past quaternions, but the
quaternions are *not commutative*. This isn't really a problem in Swift,
since the compiler never allows you to write an expression where the order
of arguments to an operator is ambiguous. This means they are *not a field*,
just a division ring  (a field
is a commutative division ring). (I believe you can't technically have a
vector space over a non-commutative ring; the generalization would be a
module . That's
probably an argument for the name ScalarArithmetic over FieldArithmetic.)

Octonions are furthermore *not associative*, which is more of a problem
since the standard library arithmetic operators are given an associativity.
We can't give that up for regular numeric types, so someone working with
octonions would just have to define their own non-associative operators
(since there's no way for the protocol requirement to specify the operator
associativity).


> That said, the ability to interpret integer literals as an arbitrary
> Arithmetic isn't used anywhere in the standard library, so I'd like to
> consider undoing
> https://github.com/apple/swift/commit/de5b03ddc41be9c5ca5e15
> d5709eb2be069286c1
> and moving ExpressibleByIntegerLiteral down the protocol hierarchy to
> BinaryInteger.
>

+1


>
> >> *## BinaryInteger*
> >>
> >> I'm a little confused by the presence of init(extendingOrTruncating:)
> for
> >> *all* binary integers. Why does it make sense to be able to write
> >> UInt16(extendingOrTruncating: (-21 as Int8)) ? In my mind,
> sign-extension
> >> only has meaning when the source and destination types are both signed.
> >>
> >
> > Here (just IMHO), I disagree. Since any binary integer can be truncated
> and
> > any can be right-shifted, it makes sense for
> `init(extendingOrTruncating:)`
> > to be available for all of them. If I understand the proposal correctly,
> > `Int(extendingOrTruncating: (-1 as Int8))` would give you a different
> > result than `Int(extendingOrTruncating: (255 as UInt8)`.
>
> Yes it would.  But the real justification for this operation is generic
> programming with integers.  It isn't possible, today, to define:
>
>   init(extending:T) where T.isNarrowerThan(Self)
>   init(truncating:T) where T.isWiderThan(Self)
>
> >> Although I would not be against a clamp() function in the standard
> library,
> >> "init(clamping:)" sounds strange to me. What about calling it
> >> "init(nearestTo:)"?  One could also de

Re: [swift-evolution] protocol-oriented integers (take 2)

[Jacob Bandes-Storch via swift-evolution]

Great work, all. I'm not sure I ever commented on SE-0104, so I've read
through this one more carefully. Here are some things that came to mind:

*## Arithmetic*

Why are ExpressibleByIntegerLiteral and init?(exactly:)
required? I could understand needing access to 0, but this could be
provided by a static property or nullary initializer. It doesn't seem like
all types supporting arithmetic operations would necessarily be convertible
from an arbitrary binary integer.


I tried to evaluate the Arithmetic protocol by considering what it means
for higher-dimensional types such as CGPoint and CGVector. My use case was
a linear interpolation function:

func lerp(from a: T, to b: T, by ratio: T) -> T {
return a + (b - a) * ratio
}

If I've read the proposal correctly, this definition works for integer and
floating-point values. But we can't make it work properly for CGVector (or,
perhaps less mathematically correct but more familiar, CGPoint). It's okay
to define +(CGVector, CGVector) and -(CGVector, CGVector), but *(CGVector,
CGVector) and /(CGVector, CGVector) don't make much sense. What we really
want is *(CGVector, *CGFloat*) and /(CGVector, *CGFloat*).

After consulting a mathematician, I believe what the lerp function really
wants is for its generic param to be an affine space
. I explored this a bit here:
https://gist.github.com/jtbandes/93eeb7d5eee8e1a7245387c660d
53b03#file-affine-swift-L16-L18

This approach is less restrictive and more composable than the proposed
Arithmetic protocol, which can be viewed as a special case with the
following definitions:

extension Arithmetic: AffineSpace, VectorSpace {  // not actually
allowed in Swift
typealias Displacement = Self
typealias Scalar = Self
}

It'd be great to be able to define a lerp() which works for all
floating-point and integer numbers, as well as points and vectors (assuming
a glorious future where CGPoint and CGVector have built-in arithmetic
operations). But maybe the complexity of these extra protocols isn't worth
it for the stdlib...


*## BinaryInteger*

I'm a little confused by the presence of init(extendingOrTruncating:) for
*all* binary integers. Why does it make sense to be able to write
UInt16(extendingOrTruncating: (-21 as Int8)) ? In my mind, sign-extension
only has meaning when the source and destination types are both signed.

Although I would not be against a clamp() function in the standard library,
"init(clamping:)" sounds strange to me. What about calling it
"init(nearestTo:)"?  One could also define a FloatingPoint version of
init(nearestTo:), i.e. lround(). For maximum annoyance and explicitness,
you could even rename the existing init(_:) to init(truncating:) to make it
clear that truncation, not regular rounding, occurs when converting from
floating-point.

*... masking shifts*

The example claims that "(30 as UInt8) &>> 11" produces 3, because it
right-shifts 30 by 3. But isn't the bitWidth of UInt8 always 8 since it's a
fixed-width type? Why should 11 get masked to 3 before the shift? (Also, it
might be a good idea to choose examples with numbers whose base-ten
representations don't look like valid binary. 😉) What use cases are there
for masking shifts? I was under the impression that "smart shifts" were
pretty much how the usual shift instructions already behaved.

(Minor: were the smart shift operators supposed to be included as
BinaryInteger protocol requirements? I only see them in the "heterogeneous
shifts" extension.)

*... init(_ source: T)*

Now a thought experiment: suppose you wanted to write an
arbitrary-precision BigInt, or any binary integer such as Int256. The
BinaryInteger protocol requires you to provide init(_
source: T). Given the source of type T, how do you access its bits? Is
repeated use of word(at:) the recommended way? If so, it might be nice to
include a "wordCount" returning the number of available words; otherwise I
suppose the user has to use something like bitWidth/(8*MemoryLayout.size),
which is pretty ugly.


*## FixedWidthInteger*

Why is popcount restricted to FixedWidthInteger? It seems like it could
theoretically apply to any UnsignedInteger.


*## Heterogenous shifts, equality, and comparison*

These look great. How will the default implementations be provided?
(Equivalent question: how would a user define their own heterogeneous
operators?) I suppose this works:

static func &>> (lhs: Self, rhs: Other) -> Self {
// delegate to the protocol requirement &>>(Self, Self)
return self &>> Self(extendingOrTruncating: rhs)
}

But for operations you can't delegate so easily... I'm imagining trying to
implement heterogeneous comparison (i.e. < ) and the best I can come up
with uses signum() and word(at:)...

Also, should these be protocol requirements so user-defined types can
specialize them?


*## Masking arithmetic*

Do &* and &+ and &- need their operands to have the same type, or could

Re: [swift-evolution] [swift-users] Implementing signum

[Jacob Bandes-Storch via swift-evolution]

On Sat, Nov 19, 2016 at 11:59 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> From some older evolution-thread:
>
> extension SignedNumberType {
> var sign: Self {
>if self == (0 as Self) {
>   return (0 as Self)
>} else if self > (0 as Self) {
>   return (1 as Self)
>}
>return (-1 as Self)
> }
> }
> --
> Adrian Zubarev
> Sent with Airmail
>

Just played with this and it turns out that due to the implicit nature of
IntegerLiteralConvertible, you don't need any of the "as Self"s:

extension SignedNumber{
var sign: Self {
if self == 0 {
return 0
} else if self > 0 {
return 1
}
return -1
}
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jacob Bandes-Storch via swift-evolution]

On Wed, Oct 19, 2016 at 10:12 AM, Alex Martini  wrote:

> Grammar changes
>
> operator → operator-head operator-characters[opt]
>
> operator-head → ! % & * + - / < = > ? ^ | ~
> operator-head → operator-dot operator-dots
> operator-character → operator-head
> operator-characters → operator-character operator-character[opt]
>
> operator-dot → .
> operator-dots → operator-dot operator-dots[opt]
>
>
> 
>
>
> I think there's a mismatch between the English and grammar.  For example,
> is +..+ allowed or not?
>
> The English rule does allow +..+ because its dots appear in a run of two.
>
> The grammar allows a run of one or more dots as an operator head, but
> never allows dots as characters appearing in the middle of an operator,
> regardless of how many dots appear next to each other.  The grammar
> wouldn't allow +..+ because the dots don't come at the beginning.
>
>
>
> Here's an alternate version of the grammar that matches the "two or more"
> rule.  Because we no longer distinguish between which characters are
> allowed as the first character of an operator vs a character inside,
> there's no longer a need for a separate operator-head.
>
> operator --> operator-character operator-OPT
>
> operator-character --> ! % & * + - / < = > ? ^ | ~
> operator-character --> operator-dots
>
> operator-dots --> .. operator-additional-dots-OPT
> operator-additional-dots --> . operator-additional-dots-OPT
>

There is a typo in that operator-character[opt] should be
operator-characters[opt]. Aside from that, though, I believe the grammar as
written accepts +..+ already. Take a look at the following series of
substitutions based on the grammar rules:

operator
operator-head operator-characters
+ operator-characters
+ operator-character operator-characters[opt]
+ operator-head operator-head
+ operator-dot operator-dots operator-head
+ . . +
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jacob Bandes-Storch via swift-evolution]

Dear Swift-Evolution community,

A few of us have been preparing a proposal to refine the definitions of
identifiers & operators. This includes some changes to the permitted
Unicode characters.

The latest (perhaps final?) draft is available here:


https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md

We'd welcome your initial thoughts, and will probably submit a PR soon to
the swift-evolution repo for a formal review. Full text follows below.

—Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro


Refining Identifier and Operator Symbology

   - Proposal: SE-
   

   - Authors: Jacob Bandes-Storch , Erica Sadun
   , Xiaodi Wu , Jonathan
   Shapiro
   - Review Manager: TBD
   - Status: Awaiting review


Introduction

This proposal seeks to refine and rationalize Swift's identifier and
operator symbology. Specifically, this proposal:

   - adopts the Unicode recommendation for identifier characters, with some
   minor exceptions;
   - restricts the legal operator set to the current ASCII operator
   characters;
   - changes where dots may appear in operators; and
   - disallows Emoji from identifiers and operators.

Prior
discussion threads & proposals

   - Proposal: Normalize Unicode identifiers
   
   - Unicode identifiers & operators
   
,
   with pre-proposal
    (a
   precursor to this document)
   - Lexical matters: identifiers and operators
   

   - Proposal: Allow Single Dollar Sign as Valid Identifier
   
   - Free the '$' Symbol!
   

   - Request to add middle dot (U+00B7) as operator character?
   


Guiding
principles

Chris Lattner has written:

…our current operator space (particularly the unicode segments covered) is
not super well considered. It would be great for someone to take a more
systematic pass over them to rationalize things.

We need a token to be unambiguously an operator or identifier - we can have
different rules for the leading and subsequent characters though.

…any proposal that breaks:

let 🐶🐮 = "moof"

will not be tolerated. :-) :-)


Motivation

By supporting custom Unicode operators and identifiers, Swift attempts to
accomodate programmers and programming styles from many languages and
cultures. It deserves a well-thought-out specification of which characters
are valid. However, Swift's current identifier and operator character sets
do not conform to any Unicode standards, nor have they been rationalized in
the language or compiler documentation.

Identifiers, which serve as *names* for various entities, are linguistic in
nature and must permit a variety of characters to properly serve
non–English-speaking coders. This issue has been considered by the
communities of many programming languages already, and the Unicode
Consortium has published recommendations on how to choose identifier
character sets — Swift should make an effort to conform to these
recommendations.

Operators, on the other hand, should be rare and carefully chosen, because
they suffer from low discoverability and difficult readability. They are by
nature *symbols*, not names. This places a cognitive cost on users with
respect to both recall ("What is the operator that applies the behavior I
need?") and recognition ("What does the operator in this code do?").
While *almost
every* nontrivial program defines many new identifiers, most programs do
not define new operators.

As operators become more esoteric or customized, the cognitive cost rises.
Recognizing a function name like formUnion(with:) is simpler for many
programmers than recalling what the ∪ operator does. Swift's current
operator character set includes many characters that aren't traditional and

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jacob Bandes-Storch via swift-evolution]

Proposal link:

https://github.com/apple/swift-evolution/blob/master/propo
sals/0144-allow-single-dollar-sign-as-valid-identifier.md


> * What is your evaluation of the proposal?
>

-1.

The proposal does not actually provide motivation for keeping $ beyond "the
Dollar library already uses it".

A more Swifty way for a library to introduce these operations would be with
extensions. Here are some suggestions, based off the first several
operations described in the library's readme:

$.at → convenience subscript(Index...) for Collection
$.chunk → convenience function for Sequence
$.compact → flatMap{$0}
$.contains → already exists as Sequence.contains
$.cycle → convenience function for Collection
$.difference → convenience function on Collection, or just use Set
operations, or filter
$.each → exists as Sequence.forEach
$.every → extension on Sequence
$.factorial → convenience method or postfix operator for Integer
$.fetch → convenience function on Collection
and so on.

It looks like the author's Cent  library is
already taking this approach.



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

Yes, but the change has already been made: removing $ as a valid identifier
;-)



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

Not really. If anything, IMO, the dollar sign feels more like an operator
character. (However, it's probably here to stay in identifiers because of
closure parameters and LLDB variables.)



> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>

The Dollar library resembles the style of JavaScript libraries such as
jQuery or Underscore, but that isn't a positive thing in my mind — as
mentioned above, the Swift way of doing things is different.



> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

Thorough reading of the proposal; brief glance at the library's readme on
GitHub.  Lots of time thinking about operator & identifier characters for a
forthcoming proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

[Jacob Bandes-Storch via swift-evolution]

+1. Haven't hit this issue personally, but I agree it's important and the
proposed solution seems like the right fix.

On Tue, Oct 11, 2016 at 2:28 PM, Nate Cook via swift-evolution <
swift-evolution@swift.org> wrote:

> Introduction
>
> This proposal addresses significant unexpected performance gaps when using
> dictionaries. It introduces type-specific collections for a Dictionary
>  instance's keys and values properties.
>
> New DictionaryKeys and DictionaryValues collections provide efficient key
> lookup and mutable access to dictionary values, enabling updates to be
> performed in-place and allowing copy-on-write optimization of stored values.
>
> 
> Motivation
>
> This proposal address two problems:
>
>- The Dictionary type keys implementation is inefficient, because
>LazyMapCollection doesn't know how to forward lookups to the
>underlying dictionary storage.
>- Dictionaries do not offer value-mutating APIs. The mutating
>key-based subscript wraps values in an Optional. This prevents types
>with copy-on-write optimizations from recognizing they are singly
>referenced.
>
> This proposal uses the following [String: [Int]] dictionary to
> demonstrate these problems:
>
> var dict = ["one": [1], "two": [2, 2], "three": [3, 3, 3]]
>
>
> 
> Inefficient dict.keys Search
>
> Swift coders normally test key membership using nil checks or underscored
> optional bindings:
>
> if dict["one"] != nil {
> // ...
> }if let _ = dict["one"] {
> // ...
> }
>
> These approaches provide the expected performance of a dictionary lookup
> but they read neither well nor "Swifty". Checking keys reads much better
> but introduces a serious performance penalty: this approach requires a
> linear search through a dictionary's keys to find a match.
>
> if dict.keys.contains("one") {
> // ...
> }
>
> A similar dynamic plays out when comparing dict.index(forKey:) and
> dict.keys.index(of:).
>
> Inefficient
> Value Mutation
>
> Dictionary values can be modified through the keyed subscript by direct
> reassignment or by using optional chaining. Both of these statements append
> 1 to the array stored by the key "one":
>
> // Direct re-assignment
> dict["one"] = (dict["one"] ?? []) + [1]
> // Optional chaining
> dict["one"]?.append(1)
>
> Both approaches present problems. The first is complex and hard to read.
> The second ignores the case where "one" is not a key in the dictionary.
> It forces its check into a higher branch and encourages forced unwrapping.
> Furthermore, neither approach allows the array to grow in place. They
> introduce an unnecessary copy of the array's contents even though dict is
> the sole holder of its storage.
>
> Adding mutation to a dictionary's index-based subscripting isn't possible.
> Changing a key stored at a particular index would almost certainly modify
> its hash value, rendering the index incorrect. This violates the
> requirements of the MutableCollection protocol.
>
> Proposed
> Solution
>
> This proposal adds a custom collection for the keys and values dictionary
> properties. This follows the example set by String, which presents
> multiple views of its contents. A new DictionaryKeys collection
> introduces efficient key lookup, while a new DictionaryValues collection
> provides a mutable collection interface to dictionary values.
>
> These changes introduce a simple and efficient way of checking whether a
> dictionary includes a key:
>
> // Performantif dict.keys.contains("one") {
> // ...
> }
>
> As a mutable collection, values enables modification without copies or
> clumsy code:
>
> if let i = dict.index(forKey: "one") {
> dict.values[i].append(1)  // no copy here
> } else {
> dict["one"] = [1]
> }
>
> Both the keys and values collections share the same index type as
> Dictionary. This allows the above sample to be rewritten as:
>
> // Using `dict.keys.index(of:)`if let i = dict.keys.index(of: "one") {
> dict.values[i].append(1)
> } else {
> dict["one"] = [1]
> }
>
>
> Detailed
> design
>
>- The standard library introduces two new collection types:
>DictionaryKeys and DictionaryValues.
>- A Dictionary's keys and values property types change from
>LazyMapCollection to these new types.
>- The new collection types are not directly constructable. They are
>presented only as views into a dictionary.
>
> struct Dictionary: ... {
> var keys: DictionaryKeys { get }
> var values: DictionaryValues { get set }
>
> // Remaining declarations
> }
> /// A collection 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Jacob Bandes-Storch via swift-evolution]

On Sat, Oct 8, 2016 at 4:00 AM, Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> It’s one of those issues where everybody agrees we could do better but
> nobody cares enough to do anything about it.
>

No, I think if you read this thread (and the others) I think you'll find
that not everyone agrees. Many are in favor, myself included, but it's
definitely not unanimous.


> In any case I think Discourse seemed to be the only real option because of
> mailing-list support. So I suppose they next step would be to submit a
> formal proposal to swift-evo on GitHub?
>

Is swift-evolution actually the right place for this conversation? I'm not
sure; it's not a language change that would have to coincide with one of
the Swift releases (3.0.1, 3.1, etc.).


>
> On 7 Oct 2016, at 20:44, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What happened to that talk? Were any decisions made internally? Any news?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 21. August 2016 um 17:36:53, Michie via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Incase, the Swift team decided to use a forum.
>
> I would like to suggest Discourse (http://www.discourse.org).
> It is one of the most reliable open-source made forum and most
> companies have been using it as their forum/community eg. Dockers,
> Let's Encrypt, etc...
>
> The Swift Team has a choice to host it on their own or pay
> discourse.org to host it for you. Hosting on their own would be more
> cheaper and gives you more control on how you want it to be set up. We
> can easily set up a mailing list to all the people watching the
> discussion and you can add in your own style of Authentication if
> needed.
>
> Slack will be very expensive because Slack cost almost $7 per active
> member per month. If you don't pay, it will definitely be limiting.
> Also, I don't think using chat for this kind of project will be more
> productive as people need to revisit some discussions.
>
> I can help the Swift Team set up Discourse if they are interested and
> they can create a subdomain: https://community.swift.org for it.
>
> Let me know.
>
> Michie :)
>
> Quoting Sean Alling via swift-evolution :
>
> > +1
> >
> > I think this is a great idea! The use of a mailing list is
> > manageable for a small (2-10) groups but doesn’t scale to the size
> > and frequency of comments/replies that the Swift Open Source project
> > has seen thus far. Not to mention, it reeks of 1996.
> >
> > I’m not sure if we should authenticate users via AppleID, because we
> > want the Swift community to remain cross-platform going forward.
> >
> > A Slack would be a great idea, for banter but may get crazy. We
> > would want the slack channels to remain subject pure (i.e., no
> > shenanigans). Email is good in this regard in that a reply is
> > expensive and therefore on-topic, whereas slack replies are cheap
> > and therefore easily off topic. Anyone have any idea to combat that?
> > Code of Conduct?
> >
> > I think in making this decision we should separate the determination
> > that the mailing lists are posing too great a burden at our scale
> > from the selection of what we should use in its stead.
> >
> > - Sean
> >
> >
> >> I think this thread should focus on the mailing list vs forum, Slack is
> >> not a forum. It could be nice to have it as an extra if we need it.
> >>
> >> It looks to me that all benefits of a mailing list can be achieved by a
> >> forum system with excellent support to read and reply using emails. But
> >> the opposite is not true, one single simple example: we can't even link
> >> related thread using email (as Tino mentioned on the Gmane thread).
> >>
> >>
> >>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Jacob Bandes-Storch via swift-evolution]

On Wed, Sep 28, 2016 at 1:46 PM, Kevin Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

> That's a bunch of complexity for no benefit. Why would you ever use this
> as a collection?


I think getting an element and an index simultaneously from, for instance,
collection.indexed().sorted(by:) or collection.indexed().first(where:)
could be quite useful.

Jacob


> The whole point is to be used in a for loop. If it was a collection then
> you'd need to have an index for that collection, so now you have an index
> that lets you get the index for another collection, which is pretty useless
> because you could just be using that underlying index to begin with.
>
> -Kevin
>
> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution wrote:
> > +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not
> `IndexedCollection`, which could also conform to Collection? With
> conditional conformances to BidirectionalCollection and
> RandomAccessCollection. This wouldn’t penalise the performance with respect
> to a simple `IndexedSequence`, would it?
> >
> > > Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3
> f2
> > >
> > > Introducingindexed()collections
> > > Proposal: TBD
> > > Author:Erica Sadun(https://github.com/erica),Nate Cook(
> https://github.com/natecook1000),Jacob Bandes-Storch(https://github.
> com/jtbandes),Kevin Ballard(https://github.com/kballard)
> > > Status: TBD
> > > Review manager: TBD
> > >
> > > Introduction
> > >
> > > This proposal introducesindexed()to the standard library, a method on
> collections that returns an (index, element) tuple sequence.
> > >
> > >
> > > Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
> > >
> > > Motivation
> > >
> > > The standard library'senumerated()method returns a sequence of pairs
> enumerating a sequence. The pair's first member is a monotonically
> incrementing integer starting at zero, and the second member is the
> corresponding element of the sequence. When working with arrays, the
> integer is coincidentally the same type and value as anArrayindex but the
> enumerated value is not generated with index-specific semantics. This may
> lead to confusion when developers attempt to subscript a non-array
> collection with enumerated integers. It can introduce serious bugs when
> developers useenumerated()-based integer subscripting with non-zero-based
> array slices.
> > >
> > >
> > > Indices have a specific, fixed meaning in Swift, which are used to
> create valid collection subscripts. This proposal introducesindexed()to
> produce a more semantically relevant sequence by pairing a
> collection'sindiceswith its members. While it is trivial to create a
> solution in Swift, the most common developer approach shown here calculates
> indexes twice:
> > >
> > > extension Collection {   /// Returns a sequence of pairs (*idx*, *x*),
> where *idx* represents a   /// consecutive collection index, and *x*
> represents an element of   /// the sequence.   func indexed()
> ->Zip2Sequence{ return zip(indices, self)   } }
> > >
> > > Incrementing an index in some collections can be unnecessarily costly.
> In a lazy filtered collection, an index increment is potentially O(N). We
> feel this is better addressed introducing a new function into the Standard
> Library to provide a more efficient design that avoids the attractive
> nuisance of the "obvious" solution.
> > >
> > > Detailed Design
> > >
> > > Our vision ofindexed()bypasses duplicated index generation with their
> potentially high computation costs. We'd create an iterator that calculates
> each index once and then applies that index to subscript the collection.
> Implementation would take place throughIndexedSequence, similar
> toEnumeratedSequence.
> > >
> > > Impact on Existing Code
> > >
> > > This proposal is purely additive and has no impact on existing code.
> > >
> > > Alternatives Considered
> > > Not yet
> > >
> > >
> > >
> > >
> > ___
> > 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] Lexical matters: identifiers and operators

[Jacob Bandes-Storch via swift-evolution]

Hi Jonathan,

I started another discussion on this a couple weeks ago. I haven't had time
to make any progress on the topic lately, but I'm hoping to do so this
weekend. Glad to hear you're interested!

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160912/027108.html

Jacob

On Sat, Oct 1, 2016 at 9:02 AM, Jonathan S. Shapiro via swift-evolution <
swift-evolution@swift.org> wrote:

> New to the list, but old hand at PL design. Was looking over the lexical
> structure of Swift 2.2 and 3.0, and I have some questions. A number of
> considerations identified in UAX31 (Unicode Identifier and Pattern Syntax)
> and UAX36 (Unicode Security Considerations) aren't obviously addressed.
>
> Here are some items that jumped out from a casual glance at the spec:
>
> 1. The specification does not appear to state any particular rules for
> compatibility or normalization in identifiers. Other Unicode-aware
> programming languages have adopted NFKC almost universally, and for good
> reason. The current identifier-head and identifier-character grammar admit
> sequences that Unicode considers malformed.
>
> 2. The specification does not appear to address any notion of Unicode
> equivalent sequences.
>
> 3. The relationship between the identifiers admitted by Swift 3 and
> identifiers admitted by UAX31 isn't clear. As a matter of cross-platform
> compatibility it would be really good if identifiers permitted by the
> default rules of UAX31 were all legal in Swift. This seems important for
> cross-language interop.
>
> Has this relationship been discussed somewhere I can catch up on?
>
> 4. Valid operators include code points that are undefined in any current
> or historical Unicode standard. That seems problematic. Future revisions to
> Unicode will eventually place *some* of those code points in the XIDS/XIDC
> categories, at which point we will have to choose between backwards
> compatibility and interop. Others will be assigned to new combining marks,
> which will want to be used in identifiers. As new languages are added to
> Unicode, compatibility concerns will exclude some groups from using
> identifiers that are natural to them.
>
>
> In order of least-to-most difficulty, I'd like to suggest some changes to
> the specification. I'm willing to implement them if agreement can be
> reached:
>
> 1. Pick a Unicode version and exclude any code point that is undefined as
> of that standard from both operators and identifiers. It's relatively easy
> and backwards compatible to move the Unicode version number forward as the
> language specification evolves.
>
> 2. Ensure that no code point in the Unicode Pattern_Syntax and
> Pattern_WhiteSpace categories are not included in identifier-head or
> identifier-character.
>
> 3. Explicitly state that no code point in (XIDS u XIDC) or
> Pattern_WhiteSpace is legal in an operator. Consider ensuring that
> everything in Pattern_Syntax *is* permitted in an operator.
>
> 4. I'd personally like to see an explicit statement of the extensions to
> XIDS/XIDC that are admitted by identifier-head and identifier-character.
> UAX31 refers to such extensions as a "profile", and explicitly allows them.
> I'm not interested in changing the identifier space unless there is
> something grossly and obviously problematic. What I'm after is enabling
> developers to be cognizant of potential interop challenges.
>
> 5. Adopt NFKC for identifiers. Specify and implement a combining algorithm
> version so that forward/backward compatibility is ensured.
>
>
> The first three are pretty trivial. The fourth would take some sleuthing,
> but it is straightforward. The fifth is real work. I'd be willing to sign
> up to any or all of these, but for a starting point I want to learn where
> things stand, what decisions have already been made, and where any current
> discussion may be happening.
>
> I very much doubt that NFKC would break existing code, if only because the
> use of malformed Unicode sequences is likely to be rare. To the extent that
> they exist in the field, they are almost certainly (a) unintentional, or
> (b) security concerns. It seems like a good thing to catch both of those
> early to the extent that we can, and to do so while the language definition
> remains somewhat fluid.
>
>
> Thanks!
>
>
> Jonathan Shapiro
>
> ___
> 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] [Proposal] Normalize Unicode Identifiers

[Jacob Bandes-Storch via swift-evolution]

This point seems moot to me because String's == checks for *canonical
equivalence* anyway.
On Thu, Sep 22, 2016 at 4:54 PM Michael Gottesman via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sep 22, 2016, at 4:19 PM, Xiaodi Wu  wrote:
>
> You mean values of type String?
>
>
> I was speaking solely of constant strings.
>
> I would want those to be exactly what I say they are; NFC normalization is
> available, if I recall, as part of Foundation, but by no means should my
> String values be silently changed!
>
>
> Why.
>
>
>
> On Thu, Sep 22, 2016 at 6:10 PM, Michael Gottesman 
> wrote:
>
>>
>> > On Sep 22, 2016, at 10:50 AM, Joe Groff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >> On Jul 26, 2016, at 12:26 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> +1. Even if it's too late for Swift 3, though, I'd argue that it's
>> highly unlikely to be code-breaking in practice. Any existing code that
>> would get tripped up by this normalization is arguably broken already.
>> >
>> > I'm inclined to agree. To be paranoid about perfect compatibility, we
>> could conceivably allow existing code with differently-normalized
>> identifiers with a warning based on Swift version, but it's probably not
>> worth it. It'd be interesting to data-mine Github or the iOS Swift
>> Playgrounds app and see if this breaks any Swift 3 code in practice.
>>
>> As an additional interesting point here, we could in general normalize
>> unicode strings. This could potentially reduce the size of unicode
>> characters or allow us to constant propagate certain unicode algorithms in
>> the optimizer.
>>
>> >
>> > -Joe
>> > ___
>> > 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] Unicode identifiers & operators

[Jacob Bandes-Storch via swift-evolution]

Side question: it looks like ICU is used by the standard library on
non-Apple platforms. Would it be possible to make it a dependency of the
compiler too? If we want to explicitly detect emoji, for instance, it'd be
nice to use a canonical library that already does it.

On Sun, Sep 18, 2016 at 12:33 PM, Jacob Bandes-Storch 
wrote:

> *TL;DR:*
>
> Swift 4 Stage 1 seeks to prioritize "Source stability features". Most
> source-breaking changes were done with in Swift 3; however, the
> categorization of Unicode characters into identifiers & operators was never
> thoroughly discussed on swift-evolution. This seems like it might be our
> last chance, and I think there are some big improvements to be had.
>
> I've gathered some information+thoughts into an early-stage pitch /
> pre-proposal. It doesn't really have a conclusion, so I'm hoping we can
> discuss these issues and come up with good (pragmatic) solutions here. I
> imagine this can morph into a proposal later.
>
> You can read the following in nicer HTML form at https://gist.github.com/
> jtbandes/c0b0c072181dcd22c3147802025d0b59
>
> I look forward to the discussion!
>
> -Jacob
> 
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Unicode identifiers & operators

[Jacob Bandes-Storch via swift-evolution]

On Sun, Sep 18, 2016 at 6:34 PM, Robert Widmann 
wrote:

> Some thoughts
>
> On Sep 18, 2016, at 3:33 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *TL;DR:*
>
> Swift 4 Stage 1 seeks to prioritize "Source stability features". Most
> source-breaking changes were done with in Swift 3; however, the
> categorization of Unicode characters into identifiers & operators was never
> thoroughly discussed on swift-evolution. This seems like it might be our
> last chance, and I think there are some big improvements to be had.
>
> I've gathered some information+thoughts into an early-stage pitch /
> pre-proposal. It doesn't really have a conclusion, so I'm hoping we can
> discuss these issues and come up with good (pragmatic) solutions here. I
> imagine this can morph into a proposal later.
>
> You can read the following in nicer HTML form at https://gist.github.com/
> jtbandes/c0b0c072181dcd22c3147802025d0b59
>
> I look forward to the discussion!
>
> -Jacob
>
> *# Background and motivation*
>
> To ease lexing/parsing and avoid user confusion, the names of custom
> identifiers (type names, variable names, etc.) and operators in Swift can
> be composed of (mostly) separate sets of characters.
>
> Using terminology from TSPL:
>
> `identifier-head`/`operator-head` are characters which can *begin *an
> identifier or operator.
>
> `identifier-character`/`operator-character` are characters which can
> appear anywhere in an identifier or operator (these are supersets of the
> `-head` sets).
>
> <https://developer.apple.com/library/content/documentation/
> Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html>
>
> (Note also that some particular arrangements of characters are reserved;
> for instance, `$` followed by digits for an implicit closure parameter, and
> "If an operator doesn’t begin with a dot, it can’t contain a dot
> elsewhere." There are also special characters in the language which are
> neither identifiers nor operators, such as: `()[]{},:@#`)
>
>
> *## Prior discussion on swift-evolution*
>
> *"Request to add middle dot (U+00B7) as operator character?"*
> <https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20151214/003176.html>
>
> *"Free the '$' Symbol!"*
> <https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20151228/005133.html>
>
> *"Proposal: Allow Single Dollar Sign as Valid Identifier"*
> <https://github.com/apple/swift-evolution/pull/354>
>
>
> Chris Lattner has said:
>
> > "...our current operator space (particularly the unicode segments
> covered) is not super well considered.  It would be great for someone to
> take a more systematic pass over them to rationalize things."
>
> > "We need a token to be unambiguously an operator or identifier - we can
> have different rules for the leading and subsequent characters though."
>
>
> I feel a bit bad having implemented the patch that banned this - it feels
> like dollar was mistakenly left out of the operator character range
> considering how well it worked in operators up to then.  Disambiguation
> with respect to other language constructs (anonymous parameters in closures
> and LLDB variables) is trivial and we already had diagnostics about it.
>

But more importantly, you were also the one who first asked for it to be an
operator character :-)
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005133.html

Did you have a formal proposal in the works for this? If so, it might be
worth reviewing separately from any other changes. $ is a more well-known
character, and probably more likely to elicit opinions than some more
obscure Unicode stuff.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

[Jacob Bandes-Storch via swift-evolution]

Hi João,
I think you should definitely put up a PR for this. I'm restarting the
discussion about allowed operator/identifier characters (
https://gist.github.com/jtbandes/c0b0c072181dcd22c3147802025d0b59), and I
think your proposal is an obvious requirement for any solution to be
complete. :-)

Jacob

On Tue, Aug 9, 2016 at 7:20 AM, João Pinheiro 
wrote:

> The crunch from Swift 3 has now passed and I'm bringing up this proposal
> again. Should I go ahead and issue a pull request for this?
>
> Sincerely,
> João Pinheiro
>
>
> On 26 Jul 2016, at 22:32, Chris Lattner  wrote:
>
>
> On Jul 26, 2016, at 12:22 PM, João Pinheiro via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This proposal [gist
> ]
> is the result of the discussions from the thread "Prohibit invisible
> characters in identifier names
> ". I hope
> it's still on time for inclusion in Swift 3.
>
>
> Hi João,
>
> Unfortunately, we’re out of time to accept new proposals.  Tomorrow is the
> last day for *implementation* work on source breaking changes to be done.
> We can talk about this next week for Swift 3.x or Swift 4.
>
> -Chris
>
>
>
> ___
> 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] Unicode identifiers & operators

[Jacob Bandes-Storch via swift-evolution]

*TL;DR:*

Swift 4 Stage 1 seeks to prioritize "Source stability features". Most
source-breaking changes were done with in Swift 3; however, the
categorization of Unicode characters into identifiers & operators was never
thoroughly discussed on swift-evolution. This seems like it might be our
last chance, and I think there are some big improvements to be had.

I've gathered some information+thoughts into an early-stage pitch /
pre-proposal. It doesn't really have a conclusion, so I'm hoping we can
discuss these issues and come up with good (pragmatic) solutions here. I
imagine this can morph into a proposal later.

You can read the following in nicer HTML form at
https://gist.github.com/jtbandes/c0b0c072181dcd22c3147802025d0b59

I look forward to the discussion!

-Jacob

*# Background and motivation*

To ease lexing/parsing and avoid user confusion, the names of custom
identifiers (type names, variable names, etc.) and operators in Swift can
be composed of (mostly) separate sets of characters.

Using terminology from TSPL:

`identifier-head`/`operator-head` are characters which can *begin *an
identifier or operator.

`identifier-character`/`operator-character` are characters which can appear
anywhere in an identifier or operator (these are supersets of the `-head`
sets).

<
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html
>

(Note also that some particular arrangements of characters are reserved;
for instance, `$` followed by digits for an implicit closure parameter, and
"If an operator doesn’t begin with a dot, it can’t contain a dot
elsewhere." There are also special characters in the language which are
neither identifiers nor operators, such as: `()[]{},:@#`)


*## Prior discussion on swift-evolution*

*"Request to add middle dot (U+00B7) as operator character?"*
<
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003176.html
>

*"Free the '$' Symbol!"*
<
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005133.html
>

*"Proposal: Allow Single Dollar Sign as Valid Identifier"*



Chris Lattner has said:

> "...our current operator space (particularly the unicode segments
covered) is not super well considered.  It would be great for someone to
take a more systematic pass over them to rationalize things."

> "We need a token to be unambiguously an operator or identifier - we can
have different rules for the leading and subsequent characters though."


*# Current state of affairs*

Swift's `identifier-head` and `identifier-character` mostly conform to the
recommendations in <
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3146.html>


The allowed operator characters include "Unicode math, symbol, arrow,
dingbat, and line/box drawing chars", however I don't believe this aligns
with any particular spec:
<
https://github.com/apple/swift/blob/08e7963/include/swift/AST/Identifier.h#L87-L121>





*## Identifiers/operators elsewhere*

There is an Unicode Standard Annex "identifier and pattern syntax" <
http://unicode.org/reports/tr31/> which defines the categories
`ID_Start`/`ID_Continue`.

<
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AID_Continue%3A%5D
>

*### ECMAScript 2015 "ES6"*

Uses `ID_Start` and `ID_Continue`, as well as `Other_ID_Start` /
`Other_ID_Continue`.


*### Haskell*

Distinguishes identifiers/operators by their general category (such as "any
Unicode lowercase letter", "any Unicode symbol or punctuation", etc.).


In particular, identifiers can start with any lowercase letter or _, and
may contain any letter/digit/'/_. This would seem to include letters like δ
and Я, and digits like ٢.


<
https://github.com/ghc/ghc/blob/714bebff44076061d0a719c4eda2cfd213b7ac3d/compiler/parser/Lexer.x#L1949-L1973
>



*# Current problems*

*## Weird identifier code points*

The current `identifier-character` set contains many characters which
wouldn't make good identifiers:

- 11 entire planes of characters (U+2–U+2FFFD, etc.) which are
currently unassigned.
- The middle dot · which looks like an operator.
- Many non-combining "modifiers" and accent marks, such as ´ and ¨ and ꓻ
which don't really make sense on their own.
- "Tone marks" from various languages, including ˫ (similar to a
box-drawing character ├ which is an operator).
- The "Greek question mark" ;
- Symbols which are simply not linguistic, such as ۞ and ༒.

short url: 

<
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Ba-zA-Z%0D%0A_%0D%0A%5Cu00A8%0D%0A%5Cu00AA%0D%0A%5Cu00AD%0D%0A%5Cu00AF%0D%0A%5Cu00B2-%5Cu00B5%0D%0A%5Cu00

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

[Jacob Bandes-Storch via swift-evolution]

On Wed, Sep 7, 2016 at 10:02 PM, Xiaodi Wu  wrote:

> On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch 
> wrote:
>
>> On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu  wrote:
>>
>>> This suggestion has been pitched earlier and I've expressed my opinion
>>> in those earlier threads, but I'll repeat myself here:
>>>
>>> I'm hugely opposed to such changes to the precedence table. Those of us
>>> who work with bitwise operators on a regular basis have memorized their
>>> precedence in Swift (and other languages) and rely on such precedence to
>>> write readable, correct code without excessively nested parentheses.
>>>
>>
>> Could you point me towards some examples of such code? I don't write it
>> very often, so I don't feel I can really evaluate this. (This seems
>> analogous to the "terms of art" categorization from the API Design
>> Guidelines threads.) Much of the code I would normally write using bitwise
>> operators has been replaced with the SetAlgebra protocol methods provided
>> on OptionSet types.
>>
>
> Gladly. These (which cannot be copied verbatim into Swift, as C operator
> precedences are different):
> https://graphics.stanford.edu/~seander/bithacks.html
>
> Lest you think I'm giving you a C example because I don't actually use
> such things in Swift, here's me using some of these:
> https://github.com/xwu/FlowKit/blob/master/Source/BitVector.swift
>
> (Note that this specific example will soon be obsolete with new integer
> protocols.)
>

Both of these actually seem to make pretty careful use of parentheses in
expressions with mixed-precedence infix operators. In the former, I find
only a small handful of cases where & is mixed with +, *, or / — seemingly
the minority.


>
> The proposals include both breaking precedence relations and changing
> them; changing them will essentially always cause silent changes in
> existing code. Removing relations won't; however, it will necessitate
> sometimes difficult migrations, as formulas are complicated.
>

I would think (hope) that any removals could easily yield automatic
migrations by adding parens where they were previously implied. I would
only be concerned with the possibility that such a migration would affect
type-checking speed (an area that already needs improvement, and can be
exacerbated by large expressions).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

[Jacob Bandes-Storch via swift-evolution]

I've filed https://bugs.swift.org/browse/SR-2582 for this.

On Tue, Sep 6, 2016 at 10:37 AM, Jordan Rose  wrote:

>
> On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev <
> swift-...@swift.org> wrote:
>
>
> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch 
> wrote:
>
> Here are a few thoughts:
>
>- -swift=4
>- -swift-version=4
>
>
> -swift-version seems like the best option to me, but Jordan will have a
> strong opinion.  I think he’s crazy busy with Swift 3 work until late next
> week.
>
>
> :-) I missed this thread. -swift-version is all right. It doesn’t
> immediately sound nice (a bit wordy) but I don’t have anything better.
>
> If I’m really getting nitpicky, I might note that we don’t really use =
> options in swiftc as much as separated operations (-swift-version 4).
>
> Jordan
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

[Jacob Bandes-Storch via swift-evolution]

On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu  wrote:

> This suggestion has been pitched earlier and I've expressed my opinion in
> those earlier threads, but I'll repeat myself here:
>
> I'm hugely opposed to such changes to the precedence table. Those of us
> who work with bitwise operators on a regular basis have memorized their
> precedence in Swift (and other languages) and rely on such precedence to
> write readable, correct code without excessively nested parentheses.
>

Could you point me towards some examples of such code? I don't write it
very often, so I don't feel I can really evaluate this. (This seems
analogous to the "terms of art" categorization from the API Design
Guidelines threads.) Much of the code I would normally write using bitwise
operators has been replaced with the SetAlgebra protocol methods provided
on OptionSet types.

Any change here would break existing, carefully constructed code, punishing
> those who *have* put in the effort to learn the precedence table. To any
> other user of Swift, it should come as no surprise that operators *have*
> precedence and associativity, and it is not such a burden for a user either
> to memorize or to consult a table for these properties when they are unsure
> .
>

> There is no way whatsoever to use intuition to arrive at the exact
> precedence of `??`, or `as`, or `&&`, or `||`, or `&`, or `|`, or `^` or
> `<<`, or `>>`, and there will be no relative precedence that will prove
> intuitive to all. (That said, there is a rational basis for the relative
> precedence of `&`, `|`, and `^` to each other.) If you believe this
> situation to be problematic, then you must conclude that we should remove
> relative precedence between any operators except perhaps the basic
> arithmetic operators `+`, `-`, `*`, `/`.
>

I hadn't really noticed until now that && and || have a defined ordering,
and can be mixed. These are operators I *do* use regularly, and mixing them
still makes me uncomfortable / seems unclear. Clang provides a warning for
this: -Wlogical-op-parentheses.

I have a hard time seeing why the bitwise and arithmetic operators should
belong to the same set of precedence groups, such that & and * are BOTH
stronger than + and |.  Even if some people are more acquainted with the
bitwise operators' precedences, as you  say, why should & be stronger than
+ ? Why should * be stronger than |  ?

How about this?

[image: Inline image 3]

(Personally, I'm comfortable with BitwiseShift being stronger than both the
other bitwise and the arithmetic operators, because it's a close cousin of
exponentiation.)


> This line of reasoning would be a huge U-turn from the direction of Swift,
> which after all just revised the syntax with which custom operator
> precedence is defined. Such a feature would be totally out of place in a
> language where operators other than those for basic arithmetic are not
> supposed to have precedence relations with each other.
>
> (Of course, the relative precedence of arithmetic operators is in some
> ways arbitrary as well, though it is inherited from math that everyone
> knows. How did you learn it in the first place? You memorized it.)
>
>
(from a later email)

The promise of Swift 3 was that going forward, only essential
> source-breaking changes would occur; here, nothing about operators has
> changed since version 1, yet all of a sudden we are considering how to
> fundamentally alter how they work. Existing code *will break*, and
> sometimes silently, if such changes are made.


How could the breakage possibly be silent for a change like this?  I'm not
proposing to add any new precedence relationships, just to remove/separate
existing ones.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] Proposal status page

[Jacob Bandes-Storch via swift-evolution]

It'd be great to see swift.org as just another repo on github.com/apple via
GitHub Pages ;-)

Jacob

On Tue, Sep 6, 2016 at 8:45 PM, Jordan Rose  wrote:

>
> > On Sep 6, 2016, at 05:47, Ben Rimmington via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> >> On 6 Sep 2016, at 07:11, Jacob Bandes-Storch 
> wrote:
> >>
> >> Is it possible to have a repo named apple.github.io, and still allow
> individual repos having their own pages (like apple.github.io/swift-
> evolution)?
> >
> > The `username.github.io` and `username.github.io/projectname`
> combination works for me.
> >
> > The `orgname.github.io` and `orgname.github.io/projectname` combination
> should also work (but I haven't tried it).
> >
> > 
> >
> > — Ben
>
> Thanks for the suggestion, Ben. After a bit of discussion we’ve put in a
> redirect to github.com/apple/, which is definitely better than just
> 404ing.
>
> Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] Proposal status page

[Jacob Bandes-Storch via swift-evolution]

Is it possible to have a repo named apple.github.io, and still allow
individual repos having their own pages (like
apple.github.io/swift-evolution)?

Jacob

On Mon, Sep 5, 2016 at 7:05 AM, Ben Rimmington via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 21 Jul 2016, at 19:10, Jordan Rose wrote:
> >
> >> On Jul 18, 2016, at 16:57, Mark Lacey wrote:
> >>
> >>> On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch wrote:
> >>>
> >>> This is now live:  http://apple.github.io/swift-evolution/
> >>
> >> Very very nice!
> >>
> >> I wonder if we should do something to avoid the 404 here though:
> http://apple.github.io
> >>
> >> Perhaps a redirect to https://github.com/apple/swift or maybe directly
> to https://github.com/apple/swift/blob/master/README.md?
> >
> > The Swift Open Source project isn’t the only project under
> github.com/apple. Any landing page here would have to come from Apple PR.
>
> You could add a simple  apple.github.io/blob/master/404.html> file:
>
> 
> 
> https://developer.apple.com/opensource/"; />
> 404 Not Found
>
> That will redirect to the URL which also appears at the top of the <
> https://github.com/apple/> page.
>
> -- Ben
>
> ___
> 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] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Jacob Bandes-Storch via swift-evolution]

>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0140-bridge-optional-to-nsnull.md
>
>
>- What is your evaluation of the proposal?
>
> I tend to agree with other commenters that NSNull does not seem like an
obviously-correct (or -unsurprising) solution to this problem. Rather than
getting "unexpectedly found nil" errors like in Swift, this would start
causing more obtuse errors about missing methods on NSNull.

Users could simply be forced to write `?? NSNull()` if they really want to
use NSNull.

I do think that a warning/error for Optional-to-Any conversion should be
added; something like:

- (void)test:(id _Nonnull)arg;
let x: Int? = 3
test(x)  // passing optional type 'Int?' to 'Any' parameter uses an
opaque wrapper; use 'as Any' to silence this warning

Although, I'm not sure that would be a complete solution, because you could
still get around it with generic algorithms. This example is contrived, but:

extension Array {
func asAnys() -> [Any] {
return map { $0 as Any }// no warning here; $0's type is
Element, not known whether optional or non-optional
}
}

It might be nice for this warning to occur *only* when passing values to
Obj-C methods. Swift code written using Any would handle them correctly.
However, I'm not sure that's possible, given that the Obj-C importer
recently started using Any instead of AnyObject on purpose to make Obj-C
code more like Swift code in that way.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Definitely; the current behavior is surprising and dangerous.



>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Not really; it seems like a Cocoa-ism leaking into the purity/safety of
Swift, more so than most bridging behavior, although perhaps I'm only
saying this because NSNull is much less commonly used than the most other
bridged types.



>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> N/A



>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> A quick reading of the proposal, plus some experimentation in a sample
project and discussion with others in Slack about an occurrence of the
motivating problem.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

[Jacob Bandes-Storch via swift-evolution]

Perhaps-conversely, what should this code do?

let nextIndex = foundIndex ?? lastIndex + 1

Jacob

On Sat, Sep 3, 2016 at 9:05 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Given: `let x = Optional(3)` then
>
> `let y = 5 + x ?? 2` will not compile
>
> but
>
> `let y = 5 + (x ?? 2)` will.
>
>
> Should NilCoalescingPrecedence be raised? The current operator precedence
> chain is:
>
> BitwiseShiftPrecedence > MultiplicationPrecedence > AdditionPrecedence >
> RangeFormationPrecedence > CastingPrecedence > NilCoalescingPrecedence >
> ComparisonPrecedence > LogicalConjunctionPrecedence >
> LogicalDisjunctionPrecedence > TernaryPrecedence > AssignmentPrecedence >
> FunctionArrowPrecedence > [nothing]
>
>
> It seems to me that `NilCoalescingPrecedence` should probably be higher
> than `MultiplicationPrecedence` and possibly higher `
> BitwiseShiftPrecedence` as its job is to produce an unwrapped value that
> can then be operated upon.
>
> I think CastingPrecedence should be even higher because
>
> `expression as? T ?? fallback value`
>
> should be parsed as
>
> `(expression as? T) ?? (fallback value)`
>
>
> I apologize profusely because I know this is beyond last minute,
>
> -- E
>
>
> ___
> 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] New feature request: syntactic sugar for "if let" scoped self assignment

[Jacob Bandes-Storch via swift-evolution]

For context, some prior discussions on this topic:

"Reconsidering SE-0003 Removing var from Function Parameters and Pattern
Matching"
(couldn't find one representative message — search it yourself
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/thread.html
)

The bind thread




On Sun, Aug 28, 2016 at 12:54 PM, Nicholas Exner via swift-evolution <
swift-evolution@swift.org> wrote:

> Dear Swift Evolution Group Members,
>  Recently, as I was reviewing some code that I wrote, I was
> wondering what the community’s thoughts are on the possible value of having
> a special “if let” self-assignment operator added to the language (such as
> =? ).  A sort of syntactic sugar that allows for optional unwrapping into a
> scoped variable of the same name as the variable in the larger scope.  Here
> is some before and after code of what I am contemplating:
>
> *Current:*
> var str:String?
> str = "Hello"
>
> if let str = str {
> print(str)
> }
>
> *Abbreviated:*
> var str:String?
> str = “Hello”   // Output is Hello, not Optional(“Hello”)
>
> if let str =? {
> print(str) // Output is also Hello, not Optional(“Hello”)
> }
>
> The value that I perceive of adding this to the language would be to allow
> a short-hand way to unwrap in a “if let" conditional and allowing
> developers to reduce duplication when a unique variable name is not
> needed.  By the way, I’m a big fan of ternary operators which the community
> already sees of value.
>
> Let me know your thoughts.  Is this something that could be put into a
> proposal?
>
> Cheers,
> —Nick—
> .
>
>
>
> ___
> 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] InternalString class for easy String manipulation

[Jacob Bandes-Storch via swift-evolution]

Here's a little prior discussion about ASCIIString:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002138.html

Jacob

On Sun, Aug 14, 2016 at 3:41 PM, Michael Savich via swift-evolution <
swift-evolution@swift.org> wrote:

> Back in Swift 1.0, subscripting a String was easy, you could just use
> subscripting in a very Python like way. But now, things are a bit more
> complicated. I recognize why we need syntax like
> str.startIndex.advancedBy(x) but it has its downsides. Namely, it makes
> things hard on beginners. If one of Swift's goals is to make it a great
> first language, this syntax fights that. Imagine having to explain Unicode
> and character size to an 8 year old. This is doubly problematic because
> String manipulation is one of the first things new coders might want to do.
>
> What about having an InternalString subclass that only supports one
> encoding, allowing it to be subscripted with Ints? The idea is that an
> InternalString is for Strings that are more or less hard coded into the
> app. Dictionary keys, enum raw values, that kind of stuff. This also has
> the added benefit of forcing the programmer to think about what the String
> is being used for. Is it user facing? Or is it just for internal use? And
> of course, it makes code dealing with String manipulation much more concise
> and readable.
>
> It follows that something like this would need to be entered as a literal
> to make it as easy as using String. One way would be to make all String
> literals InternalStrings, but that sounds far too drastic. Maybe appending
> an exclamation point like "this"! Or even just wrapping the whole thing in
> exclamation marks like !"this"! Of course, we could go old school and write
> it like @"this" …That last one is a joke.
>
> I'll be the first to admit I'm way in over my head here, so I'm very open
> to suggestions and criticism. Thanks!
>
> Sent from my iPad
>
> ___
> 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] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

[Jacob Bandes-Storch via swift-evolution]

Hi Dave,
I just filed https://bugs.swift.org/browse/SR-2303.

Brainstorming: is it important that the init(stringInterpolation:) and
init(stringInterpolationSegment:) requirements are on the same type?
Perhaps it would work to separate these two requirements, allowing the
segments to construct intermediate types, and only requiring the type
adopting ExpressibleByStringInterpolation to implement
init(stringInterpolation:).

This would be nice because it would be much easier for types which aren't
enums to conform to ExpressibleByStringInterpolation. In my auto layout
example (https://gist.github.com/jtbandes/9c1c25ee4996d2554375), the
ConstraintCollection type is only an enum because it has to provide all the
initializers, but it's strange that the cases are accessible publicly;
ideally it would just be a struct with no public initializers besides
init(stringInterpolation:). For example:

enum InterpolationSegment {
case stringLiteral(String)
case interpolatedValue(T)
}

protocol InterpolationSegmentProtocol {
// Might want to implement init(stringInterpolationSegment:) for
multiple types,
// so we can't require a single associated value (same with
ExpressibleByStringLiteral today)
//associatedtype Value
//init(stringInterpolationSegment value: Value)
}

protocol MyExpressibleByStringInterpolation {
associatedtype Segment: InterpolationSegmentProtocol
init(stringInterpolation: InterpolationSegment...)
}

// Foo is constructed from a string interpolation containing only
// String pieces and Foo.Segment pieces.
struct Foo: MyExpressibleByStringInterpolation {
struct Segment: InterpolationSegmentProtocol {
init(stringInterpolationSegment value: Int) {}
init(stringInterpolationSegment value: Double) {}
}
init(stringInterpolation: InterpolationSegment...) {
// ...
}
}

let x: Foo = "abc\(3)def"
// translated to
Foo(stringInterpolation:
.stringLiteral("abc"),
.interpolatedValue(.init(stringInterpolationSegment: 3)),
.stringLiteral("def"))


Jacob

On Mon, Aug 8, 2016 at 5:57 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Sat Jul 30 2016, Jacob Bandes-Storch  wrote:
>
> > In the past, there has been some interest in refining the behavior of
> > ExpressibleByStringInterpolation (née StringInterpolationConvertible),
> for
> > example:
> >
> > - Ability to *restrict the types that can be used* as interpolation
> segments
> > - Ability to *distinguish the string-literal segments* from interpolation
> > segments whose type is String
>
> Hi Jacob,
>
> I see you've already filed a Jira for the second bullet.  Can you file
> one for the first one?  We're going to redesign
> ExpressibleByStringInterpolation for Swift 4 and solve these problems.
>
> Thanks,
>
> > Some prior discussions:
> > - "StringInterpolationConvertible and StringLiteralConvertible
> inheritance"
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160516/017654.html
> > - Sub-discussion in "Allow multiple conformances to the same protocol"
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160606/020746.html
> > - "StringInterpolationConvertible: can't distinguish between literal
> > components and String arguments"  https://bugs.swift.org/browse/SR-1260
> > / rdar://problem/19800456&18681780
> > - "Proposal: Deprecate optionals in string interpolation"
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160516/018000.html
> >
> > About Swift 4, Chris wrote:
> >
> >>  - *String re-evaluation:* String is one of the most important
> >> fundamental types in the language.  The standard library leads have
> >> numerous ideas of how to improve the programming model for it, without
> >> jeopardizing the goals of providing a unicode-correct-by-default model.
> >> Our goal is to be better at string processing than Perl!
> >
> > I'd be interested in any more detail the team can provide on this. I'd
> like
> > to talk about string interpolation improvements, but it wouldn't be wise
> to
> > do so without keeping an eye towards possible regex/pattern-binding
> syntax,
> > and the String refinements that the stdlib team has in mind, if there's a
> > chance they would affect interpolation.
> >
> > Discuss!
> >
> > -Jacob
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

[Jacob Bandes-Storch via swift-evolution]

If you were to design this API for Swift in the first place, you might want
to do something entirely different:

extension URL {
enum Reachability {
case reachable
case notReachable(ErrorProtocol)
}
func reachability() -> Reachability
}

On Sun, Aug 7, 2016 at 12:20 PM, Félix Cloutier 
wrote:

> I read it from the Mac Developer Library's documentation, which has all of
> that for the Swift version too (link
> 
> ).
>
> I was commenting on the awkwardness of the Objective-C interface. Given
> that the error parameter is only populated when the return value is
> `false`, in the transposed Swift world, you shouldn't need to check the
> return value.
>
> Félix
>
> Le 7 août 2016 à 12:14:38, Charles Srstka  a
> écrit :
>
> On Aug 7, 2016, at 1:59 PM, Félix Cloutier  wrote:
>
>
> One line above the text that you quoted, you can read:
>
> If this method returns false, the object pointer referenced by error is
> populated with additional information.
>
>
> That’s only in the documentation for the original NSURL method (which
> still returns an error by reference). This is the entirety of the
> description in the documentation for the new one on URL:
>
> "This method synchronously checks if the resource’s backing store is
> reachable. Checking reachability is appropriate when making decisions that
> do not require other immediate operations on the resource, e.g. periodic
> maintenance of UI state that depends on the existence of a specific
> document. When performing operations such as opening a file or copying
> resource properties, it is more efficient to simply try the operation and
> handle failures. This method is currently applicable only to URLs for file
> system resources. For other URL types, false is returned.”
>
> The rationale is probably that this method was awkward to begin with. It's
> unclear to me why it was decided to return a `NSError` by reference and a
> bool that is seemingly equivalent to `error != nil`.
>
>
> It’s not like that anymore. On the new URL value type, it both returns a
> bool *and* is marked ‘throws’. So you have to check *both* whether it
> returned false *and* whether it threw an error.
>
> Charles
>
>
>
> ___
> 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] [swift-dev] [Swift 4] Organizing source stability

[Jacob Bandes-Storch via swift-evolution]

Importing the right version of a module (such as the standard library) when
more than one are available is just a search-paths problem. Supporting
multiple versions of the language's syntax and ABI, though, as far as I can
tell, requires the switch to be deeply baked into the compiler.

So I don't really see how we can get away with a "general" solution, beyond
perhaps some SwiftPM support for libraries that provide source or binaries
for multiple language versions.

On Wed, Aug 3, 2016 at 12:44 PM, Douglas Gregor  wrote:

>
> > On Aug 3, 2016, at 1:16 AM, Brent Royal-Gordon via swift-dev <
> swift-...@swift.org> wrote:
> >
> >> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>  • a top-of-file "shebang"-style comment indicating the version,
> something like //#swift(4), mirroring the "#if swift" syntax
> >
> > `import Swift 3.1`?
> >
> > I think this brings up two interesting questions:
> >
> > * Do we want to be able to mix files using different versions of Swift
> in the same module?
>
> No. It simplifies the problem greatly if the whole module is compiled with
> a single Swift version.
>
> > * Do we want to extend these backwards compatibility features beyond the
> standard library to other modules?
>
> If we can design generally-useful features for handling language
> versioning, that the standard library can adopt, that would be great.
>
> - Doug
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

[Jacob Bandes-Storch via swift-evolution]

Here's another example use case: Auto Layout visual format strings.

https://gist.github.com/jtbandes/9c1c25ee4996d2554375#file-constraintcollection-swift-L85-L87

Since only views and numeric types are supported, the generic init has
to be a run-time error. Ideally it could be a compile-time error.

On Tue, Aug 2, 2016 at 6:10 PM, Brent Royal-Gordon 
wrote:

> > On Jul 30, 2016, at 10:35 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > In the past, there has been some interest in refining the behavior of
> ExpressibleByStringInterpolation (née StringInterpolationConvertible), for
> example:
> >
> > - Ability to restrict the types that can be used as interpolation
> segments
> > - Ability to distinguish the string-literal segments from interpolation
> segments whose type is String
> >
> > Some prior discussions:
> > - "StringInterpolationConvertible and StringLiteralConvertible
> inheritance"
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html
> > - Sub-discussion in "Allow multiple conformances to the same protocol"
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html
> > - "StringInterpolationConvertible: can't distinguish between literal
> components and String arguments"  https://bugs.swift.org/browse/SR-1260 /
> rdar://problem/19800456&18681780
> > - "Proposal: Deprecate optionals in string interpolation"
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html
> >
> >
> > About Swift 4, Chris wrote:
> >  - String re-evaluation: String is one of the most important fundamental
> types in the language.  The standard library leads have numerous ideas of
> how to improve the programming model for it, without jeopardizing the goals
> of providing a unicode-correct-by-default model.  Our goal is to be better
> at string processing than Perl!
> >
> > I'd be interested in any more detail the team can provide on this. I'd
> like to talk about string interpolation improvements, but it wouldn't be
> wise to do so without keeping an eye towards possible regex/pattern-binding
> syntax, and the String refinements that the stdlib team has in mind, if
> there's a chance they would affect interpolation.
> >
> > Discuss!
>
> I'm not one of the core team, so all I can really provide is a use case.
>
> Given a LocalizedString type like:
>
> /// Conforming types can be included in a LocalizedString.
> protocol LocalizedStringConvertible {
> /// The format to use for this instance. This format string will
> be included in the key when
> /// this type is interpolated into a LocalizedString.
> var localizedStringFormat: String { get }
>
> /// The arguments to use when formatting to represent this
> instance.
> var localizedStringArguments: [CVarArg] { get }
> }
>
> extension NSString: LocalizedStringConvertible {…}
> extension String: LocalizedStringConvertible {…}
> extension LocalizedString: LocalizedStringConvertible {…}
>
> extension Int: LocalizedStringConvertible {…}
> // etc.
>
> struct LocalizedString {
> /// Initializes a LocalizedString by applying the `arguments` to
> the format string with the
> /// indicated `key` using `String.init(format:arguments:)`.
> ///
> /// If the `key` does not exist in the localized string file, the
> `key` itself will be used as
> /// the format string.
> init(key: String, formattedWith arguments: [CVarArg]) {…}
> }
>
> extension String {
> init(_ localizedString: LocalizedString) {
> self.init(describing: localizedString)
> }
> }
>
> extension LocalizedString {
> /// Initializes a LocalizedString with no arguments which uses the
> indicated `key`. `%`
> /// characters in the `key` will be converted to `%%`.
> ///
> /// If the `key` does not exist in the localized string file, the
> `key` itself will be used as
> /// the string.
> init(key: String) {…}
>
> /// Initializes a LocalizedString to represent the indicated
> `value`.
> init(_ value: LocalizedStringConvertible) {…}
>
> /// Initializes a LocalizedString to represent the empty string.
> init() {…}
> }
>
> extension LocalizedString: CustomStringConvertible {…}
>
> extension LocalizedString: ExpressibleByStringLiteral {
> init(stringLiteral value: String) {
> self.init(

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Jacob Bandes-Storch via swift-evolution]

As I mentioned at the top of this thread, Discourse provides free hosting
for community-friendly open-source projects

which
I suspect would include Swift. If not, that would indeed throw a wrench in
the idea.

On Wed, Aug 3, 2016 at 1:30 PM, Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> I’d rather the core team work on the language, stdlib and the compiler.
> Wouldn’t you agree?
>
> > On Aug 3, 2016, at 12:59 PM, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I wasn't expecting someone else to do it! This would need to be
> supported by the core team 100%
> >
> > Brandon
> >
> >> On Aug 3, 2016, at 3:42 PM, David Owens II  wrote:
> >>
> >>
> >>> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I still think it is worth doing a test to see how everyone likes it:
> >>
> >> Even if it is better, someone if going to have to either maintain the
> server and install of discourse _or_ pay discourse to host it. Until
> someone on the core team agrees to those terms, what’s the point really?
> >>
> >> Has anyone looked into the possibility of extending discourse’ mail
> support to feed into discourse instead? Then discourse would be the view
> layer instead of trying to the the truth of the data.
> >>
> >> -David
> > ___
> > 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] [Idea] Generic subscripts

[Jacob Bandes-Storch via swift-evolution]

+1 from me on this feature as well. It seems like a pretty obvious way in
which subscripts should be like functions, but aren't yet.

Would there be any need for setters and getters to have different generic
parameters? I suppose today there's only one place to specify the type of
the parameters, and the type of the value being retrieved/set, so it's a
moot point.

On Wed, Aug 3, 2016 at 6:33 AM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Aug 3, 2016, at 2:25 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I'm looking for consensus on, and a coalition for, including generic
> subscripts in Phase 1 of the Swift 4 design cycle.
> >
> > The Need
> > -
> >
> > While prototyping my deferred [SE-0132][], I ran into trouble
> introducing `RangeExpression`, an abstraction to make the introduction of
> subrange features easier. Since RangeExpression is a protocol compatible
> with any index type, it has to have an associated type, and thus cannot be
> handled with an existential. I therefore had to add an overloaded subscript
> for each type, which partially defeated the purpose of having the protocol.
> >
> > The lack of generic subscripts also forced a nasty workaround for a
> convenience subscript in [SE-0131][]. That proposal extends `Dictionary
> where Key == AnyHashable` (actually a hidden `_AnyHashableProtocol`, but
> that's a different story) with a convenience subscript which takes any
> `Hashable` type—except that, because generic subscripts are impossible, [it
> instead has to take a hidden `_Hashable` type instead][anyhash-subscript].
> >
> > The generics manifesto suggests a third use case: [a subscript that can
> take any Collection of Index][manifesto].
> >
> > The lack of this feature at the very least impacts binary compatibility
> directly. It also affects source compatibility in that features like
> subranges are designed around its absence, forcing workarounds which affect
> userspace. I see good reasons to do it now and few to delay.
> >
> > Prior Art
> > ---
> >
> > As mentioned, SE-0131 and SE-0132 would have benefited from this feature.
> >
> > After a brief and mostly positive [discussion][], Harlan Haskins and
> Robert Widmann submitted a [pull request][] late in the Swift 3 cycle for
> generic and throwing subscripts. Personally, I think throwing subscripts
> are something we should include, but they're a separate issue and may not
> be appropriate for Phase 1; I would suggest severing the two parts of the
> proposal.
> >
> > Next Steps
> > ---
> >
> > What I'd like to figure out at this point is:
> >
> > * Who is interested in this feature?
>
> I am interested in this feature, both for specific applications as well as
> because it lifts what feels like an arbitrary restriction.
>
> One very common use case is in libraries that handle loosely typed data
> (JSON, Plist, etc).
>
> It’s also worth noting that they will allow us to simulate higher-rank
> functions more directly than we can today (with subscript as function
> application).
>
> >
> > * Should it be severed from throwing subscripts?
>
> Throwing subscripts are important, but don’t necessarily need to be
> introduced at the same time as generic subscripts.  However, the use case
> of libraries that handle loosely typed data will require both.  I believe
> that use case was the motivation for the proposal introduced by Harlan and
> Robert which is why both features were included.
>
> >
> > * Does the core team agree that this is in Phase 1's scope?
> >
> > * Do the people who might be able to implement this have any comments on
> it?
> >
> >
> >
> >   [SE-0132]: <
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> >
> >   [SE-0131]: <
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md#detailed-design
> >
> >   [anyhash-subscript]: <
> https://github.com/apple/swift/blob/e051c61c4d7eb33cdbb47b8ac04eae38203a61e6/stdlib/public/core/HashedCollectionsAnyHashableExtensions.swift.gyb#L147
> >
> >   [manifesto]: <
> https://github.com/apple/swift/blob/e3d8448bbdd059a55a6e72c24d07e994afaf5926/docs/GenericsManifesto.md#generic-subscripts
> >
> >   [discussion]: <
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021450.html
> >
> >   [pull request]:  >
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > 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://list

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Jacob Bandes-Storch via swift-evolution]

I hope my replies aren't too curt — I don't want to pick a fight (any more
than I did by starting this topic), but to explore how Discourse can serve
these use cases. Feel free to re-rebut.

On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon 
wrote:

>
> I don't think enough has been said in favor of mailing lists. Some
> advantages for them:
>
> 1. Available on every platform.
>
Browsers too.


>
> 2. Performant on every platform. (Discourse, for instance, struggles on
> Android.)
>
Browsers are heavily tuned for performance, and Discourse is a relatively
lightweight site. If you prefer the performance of your email client,
there's mailing list mode.


> 3. Native on every platform.
>
Browsers too.


>
> 4. Based on open standards with multiple implementations.
>
Browsers too. You may argue that the forum itself is too centralized, but
Mailman is necessarily centralized too.

And this isn't always a positive: formatting of styled, quoted, and even
plain text is quite varied among email clients, so popular threads often
end up looking like huge messes.


>
> 5. Does not require you to proactively check swift-evolution.
>
Email notification settings, or full-on mailing list mode, or RSS, can
solve this.


> 6. Supports offline reading and drafting.
>
Mailing list mode or RSS / reply-by-email.


> 7. Supports clients with alternate feature sets.
>
Discourse has RSS feeds and JSON APIs.


>
> 8. Supports bot clients for both sending (like the CI bot) and receiving
> (like Gmane).
>
Discourse has an API
 which can
be used for posting. It also supports bot-like plugins
 which can
respond to various events, although I imagine that requires self-hosting.
External bots interested in receiving would probably need to poll RSS, or
just make use of mailing list mode as a receive hook.


> 9. Supports user-specific automatic filtering.
>
Topics and categories in Discourse each support a range of notification
options from "watching" to "muted". My understanding is that these settings
are respected by mailing list mode.


>
> 10. Users can privately annotate messages.
>
Discourse has "bookmarks", basically a way of saving individual
posts/replies for yourself. Users can also send themselves private messages

for
note-taking purposes.


>
> 11. Drafts and private messages are not visible to any central
> administrator.
>
I'm not sure whether Discourse drafts are saved on the server. Moderators
are restricted from viewing private messages
.
Of course, you can always contact someone via other means.


> 12. History is stored in a distributed fashion; there is no single point
> of failure that could wipe out swift-evolution's history.
>
This is a fair point. But:
- The Git repository of proposals is distributed.
- Discourse is as easily backed up as any other computer system:
https://meta.discourse.org/t/configure-automatic-backups-for-discourse/14855
- Users who would like a low-fidelity local copy for themselves can enable
mailing list mode.
- Anyone is free to access/archive publicly accessible content using the
APIs.


>
> 13. Usually the medium of choice for large-scale, long-running open source
> projects.
>

Is that just because people already know how to use email? Is it because
the projects are so long-running that email was the best/only choice when
they started? I'm not sure anyone has done real academic research on the
use of mailing lists in open source projects. If someone can find any, I'd
be interested to read it.


>
> I could probably go on, but I'll stop here for now.
>
> I would love to have a great web archive for swift-evolution—something
> with a really solid search function, good threading, and most of the other
> niceties of forums. It'd even be nice to have an upvote feature. But these
> are all things that you could do without taking swift-evolution off of
> email.


This seems like status quo bias to me. It's just as valid to *start* with a
great forum system, and build any desirable additional features on top, as
it is to start with a mailing list and build additional features on top.
(Discourse being open-source is a pretty big advantage in terms of the
ability to add features.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

[Jacob Bandes-Storch via swift-evolution]

In the past, there has been some interest in refining the behavior of
ExpressibleByStringInterpolation (née StringInterpolationConvertible), for
example:

- Ability to *restrict the types that can be used* as interpolation segments
- Ability to *distinguish the string-literal segments* from interpolation
segments whose type is String

Some prior discussions:
- "StringInterpolationConvertible and StringLiteralConvertible inheritance"
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html
- Sub-discussion in "Allow multiple conformances to the same protocol"
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html
- "StringInterpolationConvertible: can't distinguish between literal
components and String arguments"  https://bugs.swift.org/browse/SR-1260
/ rdar://problem/19800456&18681780
- "Proposal: Deprecate optionals in string interpolation"
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html


About Swift 4, Chris wrote:

>  - *String re-evaluation:* String is one of the most important
> fundamental types in the language.  The standard library leads have
> numerous ideas of how to improve the programming model for it, without
> jeopardizing the goals of providing a unicode-correct-by-default model.
> Our goal is to be better at string processing than Perl!


I'd be interested in any more detail the team can provide on this. I'd like
to talk about string interpolation improvements, but it wouldn't be wise to
do so without keeping an eye towards possible regex/pattern-binding syntax,
and the String refinements that the stdlib team has in mind, if there's a
chance they would affect interpolation.

Discuss!

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

[swift-evolution] [Swift4] Mailing list vs. Forum

[Jacob Bandes-Storch via swift-evolution]

Branching...

On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jul 29, 2016, at 5:14 PM, Brandon Knope  wrote:
> >
> > Chris, has the core team discussed opening up a forum for discussing
> proposal implementations.
> >
> > Some of us aren't as skilled as the core team or other contributors but
> would like to learn. A forum is a much easier place for us to post for code
> help and to help others with their questions. I think this could help get
> more involved as it would be a more comfortable format for them. Think of
> how there are Apple Developer forums and not mailing lists for iOS betas
> etc.
> >
> > I am not saying moving swift-evo to forums *yet* but I believe a lot of
> the newer programmers are more comfortable with a forum format, especially
> when it comes to help and discussing code.
> >
> > Forums for contributors would:
> > - be more familiar for a lot of the newer and not as experienced
> developers
> > - be easier to search
> > - be easier to moderate (not really a problem yet)
>
> Hi Brandon,
>
> Moving from email to a forum system has come up before, but they have some
> disadvantages.  One of major wins of email is that it is pervasive and can
> be adapted into other forms.  For example, if you haven’t seen it yet,
> check out:
> https://stylemac.com/hirundo/
>
> -Chris
>
>

We've discussed forums on swift-evolution before. Maybe it's time for
another go, with Swift 3 winding down.

For context, prior discussions are on this thread:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html

  (-1 for mailman: it's hard for me to even properly find & link to all the
prior discussion about mailing lists, because of how mailman's archive
works...)


News in the last few days is that Gmane is at least temporarily
disappearing:
https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502


I'd just like to vote once again for Discourse
:
- Excellent web interface , from the people
who brought you Stack Overflow  (built-in search, etc.)
- Read via email if that's your thing: it has "*mailing list mode*" which
includes 1-email-per-post, if that's your cup of tea
- Reply via email
 if
that's your thing
- It's open source  itself
- I believe it has ways of getting content as JSON and/or RSS, so I'd
hardly say "can be adapted into other forms" is an exclusive feature of
email.

And, Discourse provides free hosting for community-friendly open-source
projects
.
I strongly suspect 
Swift would qualify for this.


There have been several people on this list arguing in favor of mailing
lists — I encourage folks to go read the old thread for themselves.

It's worth noting there are also plenty of voices that don't get heard on
this list, because people just don't like using mailing lists. One example:
https://twitter.com/pilky/status/755105431555608580
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift 4] Organizing source stability

[Jacob Bandes-Storch via swift-evolution]

Here are a few thoughts:

   - -swift=4
   - -swift-version=4
   - -language-version=4
   - a top-of-file "shebang"-style comment indicating the version,
   something like //#swift(4), mirroring the "#if swift" syntax


On Fri, Jul 29, 2016 at 5:27 PM, Chris Lattner  wrote:

>
> On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Chris writes:
>
>> - *Source stability features: *These should be relatively small, but
>> important.  For example, we need a “-std=swift3” sort of compiler flag.  We
>> may also add a way to conditionally enable larger efforts that are under
>> development but not yet stable - in order to make it easier to experiment
>> with them.
>
>
>
> I am curious whether the team has thoughts on how to organize the compiler
> codebase in such a way that new features can be added, and possibly
> source-breaking changes made, while still keeping the old functionality
> around.
>
> Are any obvious areas that will need refactoring to make this feasible?
> (Perhaps they could be turned into StarterBugs.)
>
>
> I think this would be a great thing to do.  We need a few things:
>
> - The actual compiler flag.  It is worth bikeshedding how it is spelled.
> “-std=“ is good inspiration, but clearly the wrong specific name.
>
> - The implementation should be straight forward: the flag should get
> plumbed through to a field in swift::LangOptions.  Code that diverges can
> then check it.
>
> - Handling divergence in the standard library is another big issue.  We
> have some ideas here, but it depends on having the compiler work done
> anyway to hook into.
>
> How many versions back would the compiler be expected to support? Should
> the Swift 5 compiler still support Swift 3 code?
>
>
> To be determined.  Swift 4 should definitely support Swift 3, but Swift 5
> perhaps not.  We can decide that when Swift 4 is winding down.
>
> -Chris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Swift 4] Organizing source stability

[Jacob Bandes-Storch via swift-evolution]

Chris writes:

> - *Source stability features: *These should be relatively small, but
> important.  For example, we need a “-std=swift3” sort of compiler flag.  We
> may also add a way to conditionally enable larger efforts that are under
> development but not yet stable - in order to make it easier to experiment
> with them.



I am curious whether the team has thoughts on how to organize the compiler
codebase in such a way that new features can be added, and possibly
source-breaking changes made, while still keeping the old functionality
around.

Are any obvious areas that will need refactoring to make this feasible?
(Perhaps they could be turned into StarterBugs.)

How many versions back would the compiler be expected to support? Should
the Swift 5 compiler still support Swift 3 code?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

[Jacob Bandes-Storch via swift-evolution]

I figured that sentence was in reference to the methods currently named
flatten().

The proposal also said that the String-based version of joined(separator:)
(which are implemented separately) should have a default separator of "".
There is currently no flatten() for collections of Strings.

https://github.com/apple/swift/blob/c6e828f761fc30f7ce31de7da52814f96595/stdlib/public/core/String.swift#L769

I doubt there would be a performance difference between adding `func
joined() { return joined(separator: "") }` and changing the parameter to
`separator: String = ""`.

Jacob

On Wed, Jul 27, 2016 at 3:57 PM, Chris Lattner  wrote:

>
> On Jul 27, 2016, at 2:59 PM, Jacob Bandes-Storch 
> wrote:
>
> Does the core team have feedback on whether Collection's
> joined(separator:) should have a default separator of "", or another
> overload with no parameter?
>
>
> "The core team prefers that it remain a distinct overload of
> joined(separator:) to preserve performance.”  :-)
>
> Thanks Jacob!
>
> -Chris
>
>
> On Wed, Jul 27, 2016 at 2:56 PM, Jacob Bandes-Storch 
> wrote:
>
>> I'll get right on it.  Thanks to everyone who provided great feedback
>> during the review!
>>
>> On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Proposal Link:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
>>>
>>> The review of "SE-0133: Rename flatten() to joined()" ran from Active
>>> review July 24…26. The proposal has been *accepted*.
>>>
>>> This proposal had significant positive community feedback for aligning
>>> common operation names, but raised questions about whether ‘flatten’ was
>>> term of art, and what it would mean for related operations like ‘flatMap’.
>>> The core team discussed both sides of this debate, and decided it is best
>>> to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve
>>> its term of art.  The core team prefers that it remain a distinct overload
>>> of joined(separator:) to preserve performance.  It also requests that the
>>> returned collection types (FlattenCollection and friends) be left as-is for
>>> now, since they are not names commonly directly referenced, and we’d like
>>> to keep the change minimal.
>>>
>>> Thank you to Jacob Bandes-Storch for driving this discussion forward!
>>> Time is short, we’d appreciate it if someone could implement this ASAP.
>>>
>>> -Chris Lattner
>>> 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] [Accepted] SE-0133: Rename flatten() to joined()

[Jacob Bandes-Storch via swift-evolution]

Does the core team have feedback on whether Collection's
joined(separator:) should have a default separator of "", or another
overload with no parameter?

On Wed, Jul 27, 2016 at 2:56 PM, Jacob Bandes-Storch 
wrote:

> I'll get right on it.  Thanks to everyone who provided great feedback
> during the review!
>
> On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Proposal Link:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
>>
>> The review of "SE-0133: Rename flatten() to joined()" ran from Active
>> review July 24…26. The proposal has been *accepted*.
>>
>> This proposal had significant positive community feedback for aligning
>> common operation names, but raised questions about whether ‘flatten’ was
>> term of art, and what it would mean for related operations like ‘flatMap’.
>> The core team discussed both sides of this debate, and decided it is best
>> to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve
>> its term of art.  The core team prefers that it remain a distinct overload
>> of joined(separator:) to preserve performance.  It also requests that the
>> returned collection types (FlattenCollection and friends) be left as-is for
>> now, since they are not names commonly directly referenced, and we’d like
>> to keep the change minimal.
>>
>> Thank you to Jacob Bandes-Storch for driving this discussion forward!
>> Time is short, we’d appreciate it if someone could implement this ASAP.
>>
>> -Chris Lattner
>> 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] [Accepted] SE-0133: Rename flatten() to joined()

[Jacob Bandes-Storch via swift-evolution]

I'll get right on it.  Thanks to everyone who provided great feedback
during the review!

On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
>
> The review of "SE-0133: Rename flatten() to joined()" ran from Active
> review July 24…26. The proposal has been *accepted*.
>
> This proposal had significant positive community feedback for aligning
> common operation names, but raised questions about whether ‘flatten’ was
> term of art, and what it would mean for related operations like ‘flatMap’.
> The core team discussed both sides of this debate, and decided it is best
> to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve
> its term of art.  The core team prefers that it remain a distinct overload
> of joined(separator:) to preserve performance.  It also requests that the
> returned collection types (FlattenCollection and friends) be left as-is for
> now, since they are not names commonly directly referenced, and we’d like
> to keep the change minimal.
>
> Thank you to Jacob Bandes-Storch for driving this discussion forward!
> Time is short, we’d appreciate it if someone could implement this ASAP.
>
> -Chris Lattner
> 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] End of source-breaking changes for Swift 3

[Jacob Bandes-Storch via swift-evolution]

>
>
>- SE-0089 - Renaming String.init(_: T)
>
> 
>
>
Has anyone worked on this? I have some time in the next couple of days and
might be able to come up with an implementation in time.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jacob Bandes-Storch via swift-evolution]

On Mon, Jul 25, 2016 at 2:09 PM, David Rönnqvist 
wrote:
>
> Haskell calls the general *m (m a) -> m a* function for "join", but also
> has a specialized *[[a]] -> [a]* function called "concat". (The function
> corresponding to "flatMap" is called "bind" in Haskell (although used as an
> operator), so since neither is called flatten or flatMap it doesn't have
> the confusion where one of them would be named so).
>

There's also mapMaybe

and concatMap

and
mapM
 and
probably others. "concat" is just "concatMap id". Similarly, concatMap can
be seen as equivalent to bind with its arguments reversed, "flip (>>=)". I
personally find the plethora of similar functions confusing, but I'm not
totally fluent in Haskell's standard libraries.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jacob Bandes-Storch via swift-evolution]

On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> I'm giving the overall idea a +0 and the specific proposal as currently
> written a -1, because I think this is a much more complicated bikeshed
> than it appears to be on the surface and the proposal doesn't begin to
> address the issues.  Specifically, I'm concerned about these points:
>
> * `flatten` works on Optional> and sequences of Optional.
>   How does it make sense to rename these operations “join?”
>

Does it really? These don't work for me:

let x = [1,2,nil,4]
x.flatten()

let y = Optional(Optional(42))
y.flatten()



> * The name and semantics of `flatten` is linked to that of `flatMap`.
>   It's almost impossible to explain what `flatMap` does without
>   reference to `flatten`.  Will it make sense to explain `flatMap` in
>   terms of `joined`?
>

I think the current documentation comments do a pretty good job:

On the [T].flatMap(T -> U?) -> [U] version:
  /// Returns an array containing the non-`nil` results of calling the given
  /// transformation with each element of this sequence.

On the [T].flatMap(T -> [U]) -> [U] version:
  /// Returns an array containing the concatenated results of calling the
  /// given transformation with each element of this sequence.

(This one also mentions array.map(transform).flatten(), which would become
array.map(transform).joined().)



>
> * `flatten` is a functional term of art in the same family as `flatMap`.
>   We have good reasons to consider changing some of the other names in
>   this family, such as `filter` and `reduce`, but that idea has met with
>   significant resistance on the list.  How far should we go?  Does it
>   make sense to make this one change alone?
>

I wouldn't argue for renaming flatMap. I'm not suggesting to change the
name of flatten() because I don't like it (I do); I'm suggesting to change
it because — unlike Ruby, whose Array has #flatten and #join, but the
latter is *only* for producing strings — we seem to have the *same*
functionality behind 2 differently-named APIs.

(Actually I feel like flatMap is a more fundamental functional method in
the family of filter and reduce than flatten/joined is. flatten is just
flatMap({$0}), although as pointed out above, flatten isn't actually
available in all the places that flatMap({$0}) would work.)

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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jacob Bandes-Storch via swift-evolution]

I wasn't explicit about that in the proposal, but I was intending that
these should be renamed too. There's a minor snag: JoinedSequence already
exists. I haven't taken a close look at both implementations yet, but it's
possible we could just combine them.

On Mon, Jul 25, 2016 at 12:46 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> Shouldn't the proposal also mention renaming FlattenCollection,
> FlattenBidirectionalCollection and FlattenSequence to
> Joined*(Collection|Sequence)? Or are these going to keep their name?
>
> > On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hello Swift community,
> >
> > The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and
> runs through July 26.  Apologies for the short review cycle, but we’re
> right up against the end of source breaking changes for Swift 3.  The
> proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.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.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to 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,
> >
> > -Chris Lattner
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Jacob Bandes-Storch via swift-evolution]

>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
>
> * What is your evaluation of the proposal?
>

+1 on drop{First,Last}() → removing{First,Last}().
+1 on drop{First,Last}(_:) → removing{Prefix,Suffix}(_:).
+1 on drop(while:) → removingPrefix(while:).
+1 on starts(with:[by:]) → hasPrefix(_:[by:]).
+1 on index({of:,where:}) → firstIndex({of:,where:}).
+1 on prefix and postfix versions of ..< and the prefix version of the ...
operator. For a while I thought I might prefer labeled subscripts, but
after writing them out I agree the operators are better.

The rest is a stream of consciousness:.

I don't think postfix ... is necessary. When does one ever combine a
ClosedRange with endIndex?

I don't agree that "drop" sounds particularly scary, but I'm fine with
"removing" as an alternative to "drop"/"dropping". Scatologists will be
disappointed, I'm sure.

I'd forgotten about prefix(while:), which apparently isn't implemented yet.
I think I'd prefer if this were named prefix(where:) instead.

I'm struggling a little with the distinction between length-based and
index-based methods/subscripts. Are "prefix(_ length: Int)" and
"prefix(upTo end: Index)" really different enough that one of them should
be a subscript and the other a method? The same question applies to
prefix(through:) and suffix(from:). I kinda wish these could all be methods
or all subscripts.

I have to say I don't fully understand the need for (or benefits of)
RangeExpression and the relative(to:) API (perhaps because I don't have
much experience using the most recent collection/index/range APIs). Since
the conforming type's Bound is already required to be the collection's
Index, it seems pointless to have an API to access this as a Range...there
should just be Collection subscript methods which accept the conforming
types. I suppose it's nice to get all these for free by implementing just
one subscript function (excepting the current lack of generic
subscripts)...but is it even possible to express every RangeExpression as a
Range? What about a ClosedRange whose upperBound is Int.max? (Wasn't
that the whole point of introducing ClosedRange in the first place?)

Random question: why do we have both removeFirst and popFirst?  ...on
further reading I see you covered this in Future Directions. I'd be happy
to discuss merging these. I wonder if it's important to do for Swift 3
(although we're basically out of time)?

The name IncompleteRange makes sense, but could be a little misleading if
..<(Bound?,Bound?) is called with two non-nil operands: based on my
reading, it sounds like the returned IncompleteRange wouldn't actually
change when you call completed(by:) (since it's not actually incomplete).
However, I can't come up with any better naming suggestions.


> * 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?
>

Mostly. Not sure there's enough consistency between
subsequence-length-based and index-based APIs, namely that prefix(upTo:)
becomes a subscript but prefix(_:) doesn't.

* If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>

I've used Python and Mathematica, which both have functionality similar to
"incomplete range subscripts":

Python: http://stackoverflow.com/a/509295/23649
Mathematica: https://reference.wolfram.com/language/ref/Span.html

Based on my experience there, this is a good first (second?) step for Swift
to take.

Both Mathematica and Python support a *stride* as well as start/end indices
in their subscripting syntax. It would be nice for Swift to support
something like this, but some versions of that would require custom ternary
operators (or weird intermediate types to fake a custom ternary operator).
We might also consider labelled multi-argument subscripts like
"collection[start..https://reference.wolfram.com/language/ref/Part.html>) support
multi-dimensional arrays:  matrix[[3;;4, -5;;]] would be the submatrix
containing the last 5 entries in rows 3 and 4 of the original matrix.)


> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

A mostly-thorough reading of the proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Jacob Bandes-Storch via swift-evolution]

The latest comment from Brent on the PR indicated that it's ready, I
believe.

Jacob

On Sun, Jul 24, 2016 at 10:39 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 24, 2016, at 2:41 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Jose Cheyo Jimenez via swift-evolution  writes:
> >
> >>
> >> Is your proposal going to make the swift3 window?
> >
> > It should.  I'm planning on merging it and launching the review
> > if Chris L doesn't beat me to it (which I hope he will ;-)).
>
> I’m still waiting to be told that it is ready.  You guys appear to still
> be iterating in the PR.
>
> -Chris
> ___
> 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] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

Yep. With my proposed renaming this would work:

[["hey"], ["what"]].joined().joined(separator: “”)

But so would this, if you prefer it:

[["hey"], ["what"]].joined().joined()

On Sun, Jul 24, 2016 at 6:06 PM, Jose Cheyo Jimenez 
wrote:

> [["hey"], ["what"]].joined().joined() // proposed
>
> vs
>
> [["hey"], ["what"]].flatten().joined(separator: “”) // now
>
> I do agree that having two way of doing it now seems odd.
>
> [["hey"], ["what"]].joined(separator: []).joined(separator: “”)  // now
>
>
>
>
> On Jul 24, 2016, at 5:47 PM, Jacob Bandes-Storch 
> wrote:
>
> The thing is, joined also works on arrays-of-arrays today. The only
> difference is that flatten doesn't have a separator.
>
> We wouldn't lose what your example shows — you could do this:
>
> [["hey"], ["what"]].joined().joined(separator: “")
> On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez 
> wrote:
>
>> Here is a quick example that we would loose.
>>
>> [["hey"], ["what"]].flatten().joined(separator: “")
>>
>> [["hey"], ["what"]].flatten() //  ["hey", "what”]
>>
>> The way I think of it is flatten works on array of arrays while joined
>> works on arrays of strings.
>>
>> I guess we could do this too
>>
>> [["hey"], ["what"]].joined(separator: []).joined(separator: "")
>>
>>
>>
>> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez 
>> wrote:
>>
>> -1 for this. To me there needs to be a difference between String (which
>> is not a normal collection) and other regular collections.
>>
>> In addition, I really don’t think this proposal has the needed strong
>> support for the change.
>>
>>
>>
>>
>> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Here's a proposal draft. Comments welcome:
>>
>> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325
>>
>> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington 
>> wrote:
>>
>>>
>>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch 
>>> wrote:
>>> >
>>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington 
>>> wrote:
>>> >>
>>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>> >>>
>>> >>> In the swift-lang Slack channel, a few of us were discussing
>>> joined(separator:) and realized that flatten() does almost exactly the same
>>> thing.
>>> >>>
>>> >>> Is there interest in renaming flatten() to joined()?  Since joined
>>> takes a separator that's any Sequence, we can't have a default value for
>>> the separator parameter, but we can have a variant of joined() with no
>>> arguments.
>>> >>
>>> >> I'd like default separators for the joined() methods.
>>> >>
>>> >> <https://bugs.swift.org/browse/SR-1428>
>>> >>
>>> >> But renaming flatten() to joined() seems complicated.
>>> >>
>>> >> <
>>> https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>>> >
>>> >> <
>>> https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift
>>> >
>>> >
>>> > What makes it seem complicated? At the very least, one could just
>>> rename the flatten() function. There might also be an opportunity to
>>> combine the two files and delete some code from stdlib.
>>>
>>> There's only one joined() method (for a sequence of sequences):
>>>
>>> extension Sequence {
>>>   func joined(separator: Separator) ->
>>> JoinedSequence
>>> }
>>>
>>> There are many flatten() methods (`where` clauses omitted for brevity):
>>>
>>> extension Sequence {
>>>   func flatten() -> FlattenSequence
>>> }
>>>
>>> extension LazySequenceProtocol {
>>>   func flatten() -> LazySequence>
>>> }
>>>
>>> extension LazyCollectionProtocol {
>>>   func flatten() ->
>>> LazyCollection>
>>> }
>>>
&g

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

The thing is, joined also works on arrays-of-arrays today. The only
difference is that flatten doesn't have a separator.

We wouldn't lose what your example shows — you could do this:

[["hey"], ["what"]].joined().joined(separator: “")
On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez 
wrote:

> Here is a quick example that we would loose.
>
> [["hey"], ["what"]].flatten().joined(separator: “")
>
> [["hey"], ["what"]].flatten() //  ["hey", "what”]
>
> The way I think of it is flatten works on array of arrays while joined
> works on arrays of strings.
>
> I guess we could do this too
>
> [["hey"], ["what"]].joined(separator: []).joined(separator: "")
>
>
>
> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez 
> wrote:
>
> -1 for this. To me there needs to be a difference between String (which is
> not a normal collection) and other regular collections.
>
> In addition, I really don’t think this proposal has the needed strong
> support for the change.
>
>
>
>
> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Here's a proposal draft. Comments welcome:
>
> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325
>
> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington 
> wrote:
>
>>
>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch 
>> wrote:
>> >
>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington 
>> wrote:
>> >>
>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>> >>>
>> >>> In the swift-lang Slack channel, a few of us were discussing
>> joined(separator:) and realized that flatten() does almost exactly the same
>> thing.
>> >>>
>> >>> Is there interest in renaming flatten() to joined()?  Since joined
>> takes a separator that's any Sequence, we can't have a default value for
>> the separator parameter, but we can have a variant of joined() with no
>> arguments.
>> >>
>> >> I'd like default separators for the joined() methods.
>> >>
>> >> <https://bugs.swift.org/browse/SR-1428>
>> >>
>> >> But renaming flatten() to joined() seems complicated.
>> >>
>> >> <
>> https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>> >
>> >> <
>> https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift>
>> >
>> > What makes it seem complicated? At the very least, one could just
>> rename the flatten() function. There might also be an opportunity to
>> combine the two files and delete some code from stdlib.
>>
>> There's only one joined() method (for a sequence of sequences):
>>
>> extension Sequence {
>>   func joined(separator: Separator) ->
>> JoinedSequence
>> }
>>
>> There are many flatten() methods (`where` clauses omitted for brevity):
>>
>> extension Sequence {
>>   func flatten() -> FlattenSequence
>> }
>>
>> extension LazySequenceProtocol {
>>   func flatten() -> LazySequence>
>> }
>>
>> extension LazyCollectionProtocol {
>>   func flatten() ->
>> LazyCollection>
>> }
>>
>> extension Collection {
>>   func flatten() -> FlattenCollection
>> }
>>
>> extension BidirectionalCollection {
>>   func flatten() -> FlattenBidirectionalCollection
>> }
>>
>> So it's not a simple one-to-one rename.
>>
>> When there's no `separator` argument, will FlattenIterator perform better
>> than JoinedIterator?
>>
>> >> And what would happen to the flatMap() methods? Is flatten() a term of
>> art?
>> >>
>> >> <
>> https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
>> >
>> >
>> > I'd say flatMap is more a "term of art" than flatten. "flatten" just
>> describes literally what is being done. Frankly I'm surprised it was never
>> named flattened(). Anyway, flatMap should stay.
>>
>> ## Future directions
>>
>> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
>>
>
> That's an interesting idea. It seems to be purely additive, however, so I
> imagine it wouldn't happen until after Swift 3.
>
>
>> -- Ben
>>
>>
> ___
> 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] [Draft] Fix a typo in two String methods

[Jacob Bandes-Storch via swift-evolution]

+1

On Sat, Jul 23, 2016 at 1:41 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> World's shortest proposal:
>
>
> *Introduction*
>
> In `String`, the methods `nulTerminatedUTF8` and
> `nulTerminatedUTF8CString` have the word "null" misspelled
>
> *Motivation*
>
> There is a typo
>
> *Proposed solution*
>
> Fix the typo
>
> *Impact on existing code*
>
> Emit a fix-it for existing code
>
> *Alternatives considered*
>
> Keep on spelling "nul" without the second "l"
>
> *Acknowledgments*
>
> Thanks to Andrew Trick for confirming that the existing spelling is bizarre
>
>
> ___
> 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] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

Here's a proposal draft. Comments welcome:

https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325

On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington 
wrote:

>
> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch 
> wrote:
> >
> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington 
> wrote:
> >>
> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
> >>>
> >>> In the swift-lang Slack channel, a few of us were discussing
> joined(separator:) and realized that flatten() does almost exactly the same
> thing.
> >>>
> >>> Is there interest in renaming flatten() to joined()?  Since joined
> takes a separator that's any Sequence, we can't have a default value for
> the separator parameter, but we can have a variant of joined() with no
> arguments.
> >>
> >> I'd like default separators for the joined() methods.
> >>
> >> 
> >>
> >> But renaming flatten() to joined() seems complicated.
> >>
> >> <
> https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
> >
> >> <
> https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift>
> >
> > What makes it seem complicated? At the very least, one could just rename
> the flatten() function. There might also be an opportunity to combine the
> two files and delete some code from stdlib.
>
> There's only one joined() method (for a sequence of sequences):
>
> extension Sequence {
>   func joined(separator: Separator) ->
> JoinedSequence
> }
>
> There are many flatten() methods (`where` clauses omitted for brevity):
>
> extension Sequence {
>   func flatten() -> FlattenSequence
> }
>
> extension LazySequenceProtocol {
>   func flatten() -> LazySequence>
> }
>
> extension LazyCollectionProtocol {
>   func flatten() ->
> LazyCollection>
> }
>
> extension Collection {
>   func flatten() -> FlattenCollection
> }
>
> extension BidirectionalCollection {
>   func flatten() -> FlattenBidirectionalCollection
> }
>
> So it's not a simple one-to-one rename.
>
> When there's no `separator` argument, will FlattenIterator perform better
> than JoinedIterator?
>
> >> And what would happen to the flatMap() methods? Is flatten() a term of
> art?
> >>
> >> <
> https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
> >
> >
> > I'd say flatMap is more a "term of art" than flatten. "flatten" just
> describes literally what is being done. Frankly I'm surprised it was never
> named flattened(). Anyway, flatMap should stay.
>
> ## Future directions
>
> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
>

That's an interesting idea. It seems to be purely additive, however, so I
imagine it wouldn't happen until after Swift 3.


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

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington 
wrote:

>
> > On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
> >
> > In the swift-lang Slack channel, a few of us were discussing
> joined(separator:) and realized that flatten() does almost exactly the same
> thing.
> >
> > Is there interest in renaming flatten() to joined()?  Since joined takes
> a separator that's any Sequence, we can't have a default value for the
> separator parameter, but we can have a variant of joined() with no
> arguments.
>
> I'd like default separators for the joined() methods.
>
> 
>
> But renaming flatten() to joined() seems complicated.
>
> <
> https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
> >
> 
>

What makes it seem complicated? At the very least, one could just rename
the flatten() function. There might also be an opportunity to combine the
two files and delete some code from stdlib.

>
> And what would happen to the flatMap() methods? Is flatten() a term of art?
>
> <
> https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
> >
>

I'd say flatMap is more a "term of art" than flatten. "flatten" just
describes literally what is being done. Frankly I'm surprised it was never
named flattened(). Anyway, flatMap should stay.


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

[swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

In the swift-lang Slack channel, a few of us were discussing
joined(separator:) and realized that flatten() does almost exactly the same
thing.

Is there interest in renaming flatten() to joined()?  Since joined takes a
separator that's any Sequence, we can't have a default value for the
separator parameter, but we can have a variant of joined() with no
arguments.

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

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

[Jacob Bandes-Storch via swift-evolution]

Great!

I have an attempted implementation here. Would appreciate if someone can
kick off a CI build/test.

https://github.com/apple/swift/pull/3637
On Wed, Jul 20, 2016 at 5:38 PM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md
>
> The review of "SE-0121: Remove Optional Comparison Operators" ran from
> Active review July 12...19. The proposal has been *accepted*.
>
> Feedback has been universally positive from both the community and the
> core team, because it eliminates a surprising part of the Swift model at
> very little utility cost.
>
> Thank you to Jacob Bandes-Storch for driving this discussion forward.
>
> -Chris Lattner
> 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] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Jacob Bandes-Storch via swift-evolution]

Not that it's needed, but another +1 from me.

a.hasPrefix(p) should be true iff there exists some string x for which p+x
== a.  If p == "", then x := a satisfies this, so hasPrefix should return
true.

Jacob

On Tue, Jul 19, 2016 at 1:29 PM, Jaden Geller via swift-evolution <
swift-evolution@swift.org> wrote:

> Both `hasPrefix` and `hasSuffix` are analogous to the more general
> `hasSubset` function, which would return `true` for the empty set.
>
> On Jul 19, 2016, at 12:32 PM, Bianca via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> > Empty set is a subset of all sets.
>
> True but all sets certainly do not _contain_ the empty set, which is what
> might be confusing, as the word "contains" in the context of sets implies
> that it's a member of the set of characters that make up a String.
>
> On Tue, Jul 19, 2016 at 12:23 PM Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jul 19, 2016, at 6:17 PM, Ted F.A. van Gaalen via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > 1.  return “false”  seems to me logically correct, because
>> > there is never an empty string in another string, and an empty
>> string cannot contain another empty string, right?
>>
>> Empty set is a subset of all sets.
>>
>> Just like:
>>
>> let arr1: [String] = ["Hello", "Swift", "Evolution"]
>> let arr2: [String] = []
>> arr1.starts(with: arr2, isEquivalent: ==) // true
>>
>> >This has worked very conveniently for NSString in ObjC for more than
>> 20 years, why change it?
>> >Do you know of cases that were problematic with this convention?
>> >
>> >
>> > 2  throw a runtime error when trying to do this:
>> >str.hasPrefix(“”) //  also for hasSuffix,  str.contains etc.
>> >
>> > some in-line questions below.
>> >
>> > Kind Regards
>> >
>> > Ted
>> >
>> >
>> > On 19.07.2016, at 16:31, Dave Abrahams  wrote:
>> >>
>> >>
>> >> on Tue Jul 19 2016, "Ted F.A. van Gaalen" > > wrote:
>> >>
>> >>> Hi Dave
>> >>>
>> >>> “true” ? am I going nuts ? :o)
>> >>>
>> >>> var str = "Hello, playground"
>> >>>
>> >>> print( str.hasPrefix("”)) // case 1 : false
>> >>>
>> >>> print( str.hasSuffix("”)) // case 2 : false
>> >>>
>> >>> print("" == “a” )  // case 3 : false
>> >>>
>> >>> Currently, all cases above evaluate to “false”
>> >>> i think that is correct,
>> >>
>> >> I don't know what to tell you.  It may seem intuitively correct to you,
>> >> but others in the thread have laid out the reasons why it is not
>> >> mathematically correct behavior.
>> > Where? I couldn’t find any.
>> >> One other way of rephrasing it: to get
>> >> `false` for str.hasPrefix(""), you actually need special-case code in
>> >> hasPrefix to check for the empty string,
>> > again, maybe it should throw a run-time error instead.
>> >
>> >
>> >> and the caller may well also
>> >> need special-case code to handle the fact that the result is not
>> >> mathematically consistent with other cases on the continuum.
>> > In this context as “continuum” :
>> >   are you referring to  “sets” or “collections” here?
>> > what other cases?
>> >
>> >> Doing
>> >> things that way doesn't work in practice for real programs.
>> > please explain thank you, because I see no problems at
>> > all with the current NSString-like evaluation…
>> > I’d put an s.isEmpty() in front of it.
>> >>
>> >>> because:
>> >>>
>> >>> How can an empty string be a prefix or suffix value?
>> >>> as there is no empty string present in a non-empty string.
>> >>>
>> >>> Note that if case 1 and case 2 would evaluate to “true”,
>> >>> it would conflict with case 3.
>> >>>
>> >>> Can’t imagine that case 3 should in future also result in “true”
>> >>>
>> >>> ??
>> >>>
>> >>> -
>> >>>
>> >>> Also I hope that changes to String functionality
>> >>> for Swift 4 are not backward breaking changes
>> >>> even the more for string handling, because Strings
>> >>> are heavily used in most apps.
>> >>>
>> >>> I am firmly convinced that all future releases of Swift
>> >>> should compile Swift 3 and higher source files without
>> >>> any changes 100 % flawlessly! This prevents early diminishing
>> >>> of Swift’s popularity, especially with those building large
>> >>> codebases using Swift.
>> >>>
>> >>> I’ve started a thread about this a week ago,
>> >>> however no one found this important enough to
>> >>> share their opinions with me yet, or were too busy with
>> >>> other subjects to do so.
>> >>>
>> >>> Increasingly I have dreams, me
>> >>> programming complete apps in Smalltalk
>> >>> and then automagically generate
>> >>> an macOS, tvOS or iOS runtime app of it.
>> >>>
>> >>> (I have also dreams of this world becoming
>> >>> a nice and peaceful placebut that is
>> >>> beyond the context of this forum)
>> >>>
>> >>> Kind Regards
>> >>> TedvG
>> >>>
>> >>> www.speyer.de
>> >>>
>>  on Mon Jul 18 2016, Kevin Nattinger > > wrote:
>> 
>> > I agree, true is definitely the

Re: [swift-evolution] [Meta] Proposal status page

[Jacob Bandes-Storch via swift-evolution]

I'm not sure whether it's possible to have both an "organization page" and
a "project page" (used for both swift-evolution and swift-internals).
Someone could certainly try it out.
https://help.github.com/articles/user-organization-and-project-pages/

Jacob

On Mon, Jul 18, 2016 at 4:57 PM, Mark Lacey  wrote:

>
> On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is now live:  http://apple.github.io/swift-evolution/
>
>
> Very very nice!
>
> I wonder if we should do something to avoid the 404 here though:
> http://apple.github.io
>
> Perhaps a redirect to https://github.com/apple/swift or maybe directly to
> https://github.com/apple/swift/blob/master/README.md?
>
> Mark
>
>
> On Fri, Jul 15, 2016 at 8:08 AM, Thorsten Seitz 
> wrote:
>
>> Cool! Looks great!
>>
>> -Thorsten
>>
>> Am 14.07.2016 um 10:30 schrieb Jacob Bandes-Storch via swift-evolution <
>> swift-evolution@swift.org>:
>>
>> I got sidetracked today and mocked up a proposal "status page":
>>
>> http://jtbandes.github.io/swift-evolution/
>>
>> This moves the proposal status info (currently in README.md) into a
>> separate "source of truth":
>>
>> https://github.com/jtbandes/swift-evolution/blob/master/proposals.xml
>>
>> The status page is then generated from the source of truth using XSLT.
>> Unfortunately, in order to get this working on GitHub Pages, I had to load
>> the files using JavaScript (otherwise the browser blocks the cross-origin
>> requests):
>> https://github.com/jtbandes/swift-evolution/blob/gh-pages/index.html.
>>
>>
>> If we wanted to adopt this for the official swift-evolution repo, the
>> steps would be:
>>
>> 1. push the XML and XSL files to master
>>
>> 2. push a gh-pages branch with the status page
>>
>> 3. update README.md on master to point to the status page, rather
>> than duplicating all the information.
>>
>>
>> Thoughts? Tweaks? Insults?
>>
>> Jacob
>>
>> ___
>> 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