Re: [swift-evolution] [Review] SE-0174: Change `filter` to return an associated type

[Jaden Geller via swift-evolution]

I think that the alternatives considered section isn’t entirely correct. Even 
if we had a more expressive type system, it would not be possible to make the 
return value of `map` preserve the element type *while* still allowing types 
like `String`, which aren’t parameterized by an element, to conform.

I think this would require two separate mapping protocols (ignore the straw man 
names and syntax):

protocol Mappable: Sequence {
func map(_ transform: (Iterator.Element) -> Iterator.Element) -> Self
// could also add `mapInPlace`
}

protocol MappableFunctor: Mappable {
kind Self
func map(_ transform: (Iterator.Element) -> T) -> Self
}

I think we’d also require either a way for the generic function to conform to 
the non-generic signature if there exists a conforming instantiation if both 
functions were to have the same name.

Also, we’d probably want a way to say that the `T` in the generic signature has 
the same type constraints as the generic parameter would need to…

—

Anyway, the point is that we *could* consider adding the first protocol right 
now (or more likely, add the requirement to `Sequence`) even though the second 
protocol is not possible yet. Even if/when Swift’s type system can handle that, 
the first protocol will still be necessary for types like `String` that cannot 
conform to the second.

Cheers,
Jaden Geller
 
> On Apr 28, 2017, at 5:06 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0174 "Change `filter` to return an associated type" begins 
> now and runs through May 3, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.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/0174-filter-range-replaceable.md
>  
> 
> Reply text
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug Gregor
> 
> 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] [Review] SE-0174: Change `filter` to return an associated type

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0174 "Change `filter` to return an associated type" begins now 
and runs through May 3, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.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/0174-filter-range-replaceable.md
Reply text
Other replies
 What goes 
into a review?

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

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

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

Thank you,

-Doug Gregor

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

[swift-evolution] [Accepted] SE-0170: NSNumber bridging and Numeric types

[Ben Cohen via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md

The review of SE-0170 “NSNumber bridging and Numeric types” ran from April 14 
to April 21, 2017. The proposal is accepted for Swift 4. Thanks to everyone who 
participated!

Ben
Review Manager



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

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

[Felipe Cypriano via swift-evolution]

This new proposal is great, I'm all in.


On Wed, Apr 26, 2017, at 17:25, Rick Ballard via swift-evolution wrote:> Hi all,
> 
> We have a proposal we'd like feedback on to revise how Swift Package
> Manager dependency resolution, updating, and pinning works. These
> changes weren't planned in the roadmap we published a few months ago,
> but it's become clear since then that we have some holes in our
> dependency resolution behavior that need fixing. We've also come to
> the conclusion that our original design for pinning was
> overcomplicated and should be revised.> 
> Please give us your feedback; we're hoping to submit this proposal for
> official review next week.> 
> The current draft of the proposal can be found at
> https://github.com/rballard/swift-evolution/commit/e5e7ce76f29c855aa7162ed3733b09e701d662d6.
> I'm also including it below.> 
> Thanks,
> 
> - Rick
> 
> Package Manager Revised Dependency Resolution


>  * Proposal: SE-[1]
>  * Author: Rick Ballard[2]
>  * Review Manager: TBD
>  * Status: Draft in progress
>  * Bug: TBD> Introduction


> This proposal makes the package manager's dependency resolution
> behavior clearer and more intuitive. It removes the pinning commands
> (swift package pin & swift package unpin), replaces the swift package
> fetch command with a new swift package resolve command with improved
> behavior, and replaces the optional Package.pins file with a
> Package.resolved file which is always created during dependency
> resolution.> Motivation


> When SE-0145 Package Manager Version Pinning[3] was proposed, it was
> observed that the proposal was overly complex. In particular, it
> introduced a configuration option allowing some packages to have
> autopinning on (the default), while others turned it off; this option
> affected the behavior of other commands (like swift package update,
> which has a --repinflag that does nothing for packages that use
> autopinning). This configuration option has proved to be unnecessarily
> confusing.> In the existing design, when autopinning is on (which is true by
> default) the swift package pin command can't be used to pin packages
> at specific revisions while allowing other packages to be updated. In
> particular, if you edit your package's version requirements in the
> Package.swift manifest, there is no way to resolve your package graph
> to conform to those new requirements without automatically repinning
> all packages to the latest allowable versions. Thus, specific,
> intentional pins can not be preserved without turning off autopinning.> The 
> problems here stem from trying to use one mechanism (pinning) to
> solve two different use cases: wanting to record and share resolved
> dependency versions, vs wanting to keep a badly-behaved package at a
> specific version. We think the package manager could be simplified by
> splitting these two use cases out into different mechanisms ("resolved
> versions" vs "pinning"), instead of using an "autopinning" option
> which makes these two features mutually-exclusive and confusing.> 
> Additionally, some dependency resolution behaviors were not well-
> specified and do not behave well. The package manager is lax about
> detecting changes to the versions specified in the Package.swift
> manifest or Package.pinspinfile, and fails to automatically update
> packages when needed, or to issue errors if the version requirements
> are unsatisfiable, until the user explicitly runs swift package
> update, or until a new user without an existing checkout attempts to
> build. We'd like to clarify and revise the rules around when and how
> the package manager performs dependency resolution.> Proposed solution


> The pinning feature will be removed. This removes the swift package
> pin and swift package unpin commands, the --repin flag to swift
> package update, and use of the Package.pins file.> In a future version of the 
> package manager we may re-introduce
> pinning. If we do, pins will only be recorded in the Package.pins file
> when explicitly set with swift package pin, and any pinned
> dependencies will *not* be updated by the swift package update
> command; instead, they would need to be unpinned to be updated. This
> would be a purely additive feature which packages could use in
> addition to the resolved versions feature when desired.> A new "resolved 
> versions" feature will be added, which behaves very
> similarly to how pinning previously behaved when autopinning was on.
> The version of every resolved dependency will be recorded in a
> Package.resolved file in the top-level package, and when this file is
> present in the top-level package it will be used when performing
> dependency resolution, rather than the package manager finding the
> latest eligible version of each package. swift package updatewill
> update all dependencies to the latest eligible versions and update the
> Package.resolved file accordingly.> Resolved versions will always be recorded 
> by the package 

Re: [swift-evolution] [pitch] Comparison Reform

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 28 Apr 2017, at 01:51, Jonathan Hull via swift-evolution 
>  wrote:
> 
> To be clear, the big downside is the current lack of hardware support. There 
> are apparently some chips in the pipeline, but nothing for Apple platforms 
> that I know of.

Synergy between HW and SW... fully custom ARMv8 cores... wink wink... nudge 
nudge ;). Maybe if they become super important for Swift there is an economic 
advantage for their own chips to push for them (Desktop and MacBook are more of 
an issue and depend on a whole other set of factors to happen).

> We are likely to see them first in GPUs and neural network processors (since 
> they allow effective neural networks using only 8-bit values, and the binary 
> representation dramatically simplifies some standard neural network 
> calculations). Most language implementations currently use a backing Int as 
> storage.
> 
> That said, I think it is still a worthwhile pursuit, especially for those of 
> us interested in accurate numerical calculations.  According to the author, 
> they should also be able to be used interchangeably with Floats in any 
> generic algorithm, though the results would differ (because of the increased 
> accuracy/range).  I am still reading to find the details.
> 
> If we are interested, I think the first step would be making a third party 
> library...
> 
> Thanks,
> Jon
> 
> 
>> On Apr 27, 2017, at 4:35 PM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> There have been a bunch of updates since then (currently under peer review), 
>> which deal with implementation on current systems.  Reading the new/updated 
>> paper now…
>> 
>> Here is a video of the author speaking about some of the general ideas:
>> https://www.youtube.com/watch?v=aP0Y1uAA-2Y
>> 
>> I doubt we would get rid of Double/Float, but I would love to see it used as 
>> a core type in Swift 5.  In addition to the increase in accuracy/expressible 
>> range, and the simplification of exception handling, apparently the results 
>> when used in neural networks are amazing.  It also allows you to simplify a 
>> bunch of numerical algorithms, because you don’t have to worry about some of 
>> the things that go wrong with traditional floats/doubles.
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Apr 27, 2017, at 2:35 PM, Matthew Johnson  wrote:
>>> 
>>> I mentioned unums on the list about a year ago.  Steve Canon replied with 
>>> some thoughts: 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html.
>>> 
 On Apr 27, 2017, at 4:26 PM, Jonathan Hull via swift-evolution 
  wrote:
 
 I have read it, and it is a truly brilliant work.  I would love to see 
 some (or all) of it make it into Swift (most likely Swift 5 or 6).  The 
 author is related to a friend of mine, so I can see if he is available to 
 answer questions if there is interest...
 
 
> On Apr 27, 2017, at 5:14 AM, Björn Forster via swift-evolution 
>  wrote:
> 
> Hi all together, 
> I was just looking quickly over an article from Wolfram which covers new 
> books covering Mathematica and tripped over this book:
> 
> https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/p/book/9781482239867
> 
> 
> From the reviews:
> "This book is an extraordinary reinvention of computer arithmetic and 
> elementary numerical methods from the ground up. Unum arithmetic is an 
> extension of floating point in which it is also possible to represent the 
> open intervals between two floating point numbers. This leads to 
> arithmetic that is algebraically much cleaner, without rounding error, 
> overflow underflow, or negative zero, and with clean and consistent 
> treatment of positive and negative infinity and NaN. These changes are 
> not just marginal technical improvements. As the book fully demonstrates, 
> they lead to what can only be described as a radical re-foundation of 
> elementary numerical analysis, with new methods that are free of rounding 
> error, fully parallelizable, fully portable, easier for programmers to 
> master, and often more economical of memory, bandwidth, and power than 
> comparable floating point methods. The book is exceptionally well written 
> and produced and is illustrated on every page with full-color diagrams 
> that perfectly communicate the material. Anyone interested in computer 
> arithmetic or numerical methods must read this book. It is surely 
> destined to be a classic."
> —David Jefferson, Center for Advanced Scientific Computing, Lawrence 
> Livermore National Laboratory 
> 
> I haven't read it myself, as said I stepped just over it, but *MAYBE* it 
> covers the NaN problem in depth and the current state of art how to deal 
>