Re: [swift-evolution] [Review] SE-0063: SwiftPM System Module Search Paths

[Ankit Agarwal via swift-evolution]

> * What is your evaluation of the proposal?
>

I am in favour of this proposal. It will solve an important problem faced
by swiftpm users.


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

Yes, system modules often require extra flags and search paths are platform
dependent. A lot of users have reported bugs in jira about this.


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

Yes, it will improve the functionality of swiftpm


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

I implemented the first draft of proposal and tried using GTK3 library on
OSX and Ubuntu, It works out really nice. More info about the experiment :
http://ankit.im/swift/2016/03/26/improving-system-modules-support-in-swiftpm/


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

[swift-evolution] SE-0062 Referencing Objective-C key-paths

[Les Pruszynski via swift-evolution]

This is my first post on this list so please bear with me.

I very much like this proposal but what bothers me is this doubling of 
valueForKeyPath(#keyPath(xxx) in the signature of the function.

chris.valueForKeyPath(#keyPath(Person.bestFriend.lastName)) // => Groff
chris.valueForKeyPath(#keyPath(Person.friends.firstName)) // => ["Joe", 
"Douglas"]

I’m not sure whether the form below is actually possible. For me it reads more 
naturally and is more consistent with “Modern Swift” as far as I know.

chris.valueFor(#keyPath(Person.friends.firstName)) // => ["Joe", "Douglas”]
or maybe
chris.valueOf(#keyPath(Person.friends.firstName)) // => ["Joe", "Douglas”]

Just my observation.
Regards___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0062: Referencing Objective-C key-paths

[Brent Royal-Gordon via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md

>   • What is your evaluation of the proposal?

I'm definitely in favor and look forward to using #keyPath. I have one note, 
one suggestion and one concern, but even without any of them being addressed, I 
would want to see this proposal become part of Swift.

* * *

The note: The Collection crossing might apply only to types which offer `Index 
-> Element` and `Range -> SubSequence` subscripts, but no others. That 
would include Array and Set but exclude Dictionary.

On the other hand, NSDictionary *does* have KVC behavior: the particular key is 
unconstrained and it always results in an instance of the dictionary's 
ObjectType. #keyPath could usefully support that in some way.

* * *

The suggestion: Many key paths are immediately passed to methods on the object 
they will eventually act on. For example:

chris.value(forKeyPath: #keyPath(Person.friends.firstName))

It would be nice if we could use leading dot to refer to the type of the object 
the key path is being passed to:

chris.value(forKeyPath: #keyPath(.friends.firstName))

Leading dot does not have any other useful meaning in this context; it would 
always refer to a static variable on String, which is not a sensible key path 
to try to construct.

* * *

The concern: I'm a little worried that the "value expression" feature can be 
ambiguous when accessing properties of `self`. Consider these expressions (as 
they might appear in the `Person.find(name:)` example):

#keyPath(firstName.uppercased)  => "firstName.uppercased"
#keyPath(name.uppercased)   => "uppercased"

Although they look quite similar, they end up giving very different behaviors 
because `firstName` is a property while `name` is a variable. I think this 
could be misleading—particularly because it'll be tempting to say things like 
this:

firstName.value(forKeyPath: #keyPath(firstName.uppercased)) // 
oops, that's getting `self.firstName.firstName.uppercased`!

I see two simple but inconsistent alternatives here, and one which is more 
complex but also more consistent:

1. Require `self` for a property's key path. This makes it clear that you're 
going to get "firstName.uppercased", but it's a little inconvenient in the 
plain `firstName` case, which isn't ambiguous.

2. Require `self` for a property's key path only when there are additional 
parts to the key path. In other words, you can say `#keyPath(firstName)`, but 
firstName.uppercased's keypath has to be written 
`#keyPath(self.firstName.uppercased)`. This removes the inconvenience of #1, 
but it's a complicated rule to explain.

3. Change the syntax entirely so that the thing you're looking for the key path 
of goes before the #keyPath keyword. This would make it crystal clear which 
part is the key path and which part merely specifies the type the key path will 
be used on; it would also allow you to use a more complicated expression to 
provide the type. Examples:

Person.#keyPath(firstName.uppercased)
self.#keyPath(firstName.uppercased)
#keyPath(firstName.uppercased)  // Implicit `self`

// Here's an example of a complicated path to the object you want to 
work from
textView.layoutManager.typesetter.#keyPath(usesFontLeading)

// The leading dot feature I asked for would look like:
chris.value(forKeyPath: .#keyPath(friends.firstName))

This looks weird when you're not used to it, but it's not really that strange 
an idea conceptually; if #foo() is a compile-time function, this is a 
compile-time method.

* * *

Despite these concerns, I really like this proposal a lot, and I hope to see it 
be accepted.

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

Yes. Simply put, stringly-typed code is a menace, but often a necessary one. 
Anything that makes it safer is a winner in my book.

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

Yes. It's particularly reminiscent of #selector, but it actually goes further 
by providing a feature people had to hack into Objective-C with horrible macros.

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

That's...actually kind of an interesting question. But my thoughts on that 
matter are not on topic for this review, so for now I'll say no, I don't have 
any relevant experience.

(Well, I have seen various horrible macros which offer some semblance of typo 
safety for KVC. But these are best not spoken of.)

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

I read the proposal and participated in the discussion.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave via swift-evolution]

> On Mar 30, 2016, at 12:26 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I didn't seem to ever need division. See attached playground (which
> borrows shamelessly from existing code and Erica's proposal, and which
> is written in Swift 2.2 because that's what I had handy).

Appending the following code to the playground reveals a bug/glitch:
import Darwin
let start = pow(2.0, 54)
let end = nextafter(start, Double.infinity)
let containsRepeatedValues = Array((start..

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[David Waite via swift-evolution]

> On Apr 7, 2016, at 6:12 PM, Douglas Gregor via swift-evolution 
>  wrote:

> With my proposal, we’d have some compiler-synthesized attribute (let’s call 
> it @__caller_default_implementation) that gets places on Objective-C optional 
> requirements when they get imported, e.g.,
> 
> @objc protocol NSTableViewDelegate {
>   @__caller_default_implementation func tableView(_: NSTableView, viewFor: 
> NSTableColumn, row: Int) -> NSView?
>   @__caller_default_implementation func tableView(_: NSTableView, 
> heightOfRow: Int) -> CGFloat
> }

If I understand correctly:

1. Optional methods in protocols imported from objective C gain a special flag 
when imported as Swift methods
2. Such methods can be unimplemented (such that the message will fail, or 
responds(to:) returns false) in objective-c code and bridged swift instances.
3. To implement that protocol in swift, you must have implementations of every 
protocol method, including optional ones
4. This means that there may be manual work around bridging protocols with 
optional messages into swift.
5. If the method implementation is marked @nonobjc it will fulfill the swift 
requirement that there be a method implementation, but that implementation will 
not be exposed to Objective-C
6. Swift code can call such a @nonobjc implementation, while Objective-C code 
will consider there to be nothing there.
7 An implementation that is only be applied to the swift variant is possibly 
fine in extensions while generates a warning within a swift class, or perhaps 
requires an explicit @nonobjc attribute.

I like it, except for the requirement for a manual implementation in Swift 
before you can support the protocol. 

I looked at whether the protocol members might be implemented by returning the 
nil/zero/false value you would get if you sent the message to nil. 

Cursory search quickly hit NSAccessibilityElement, which has an optional 
“accessibilityIdentifier” method returning a non-nil NSString. I suspect that 
the method also requires the string to be non-empty. Thus, a default 
implementation that represents the right thing to represent in a generated 
default implementation would likely be brittle.

I could also see an imported protocol where *any* default implementation of the 
optional method would not meet the requirements of an actual implementation of 
the method (not being versed in this particular interface, I’ll just straw man 
that the identifier is required to be unique within an application)

Thus I wonder if there may be some other way to support the idea of two 
distinct protocols, the protocol as defined in Objective C, and the protocol as 
defined in Swift.

Options that sprang to mind:
- the methods which return optional values have a default implementation that 
returns nil. Methods which return non-optional values will have the Swift 
protocol modified to return an Optional value, which they will do by default. 
So for example, Still on NSAccessibilityElement,

-(BOOL)isAccessibilityFocused

would be imported as

func isAccessibilityFocused() -> Bool?

with a default implementation returning nil. To actually implement the 
objective C protocol’s optional method, you must implement the version with the 
correct nullability variant, so in this case:

 @objc func isAccessiblityFocused() -> Bool { return focused }

(Of course, this means that a non-optional result value would need to satisfy 
an optional result valued variant in a protocol)

- similar to the above, but rather than overriding result values to support a 
default variant, overload ErrorType. Imported variants which throw will by 
default throw a bridging-specific ErrorType when called from Swift. Optional 
methods which do not throw will have a throwing variant generated on the Swift 
side. 

Again similar to the above, to satisfy the objective-C protocol requirement 
your implementation would need to be non-throwing.

I like this better in terms of capturing to the best of ones ability the 
‘spirit’ of optional methods and behavior in swift. However, this seems like it 
will result in more deviation between the Swift and Objective-C protocol method 
signatures.

Comments?

-DW

> 
> And “optional” disappears from the language. Now, there’s no optionality 
> left, so our useDelegate example tries to just do correct calls:
> 
> func useDelegate(delegate: NSTableViewDelegate) -> NSView? {
>   let view = delegate.tableView(tableView, viewFor: column, row: row)
>   let height = delegate.tableView(tableView, heightOfRow: row)
> }
> 
> Of course, the code above will fail if the actual delegate doesn’t implement 
> both methods. We need some kind of default implementation to fall back on in 
> that case. I propose that the code above produce a compiler error on both 
> lines *unless* there is a “default implementation” visible. So, to make the 
> code above compile without error, one would have to add:
> 
> extension NSTableViewDelegate {
>  

[swift-evolution] SE-0064: Referencing the Objective-C selector of property getters and setters

[William Jon Shipley via swift-evolution]

What is your evaluation of the proposal?

Strong yes.

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

At Delicious we wrote a huge ugly macro set to define properties in a special 
way so we could make key paths safely:

// Declares a safe-KVC-accessible property
// Use as: @property (opts) MyType KVC(*name);
// Use as: @property (opts) MyType KVC2(*firstName, *lastName);
#define KVC(a) \
a; SAFE_KVC(a)

#define SAFE_KVC(NAME) \
void NAME ## $DMSafeKVC(void)

#define K(x) \
__builtin_choose_expr(sizeof( ## $DMSafeKVC), @#x, @"_NOT_A_KEY_")

So you could then use K(title) for example in your code and get what would now 
be #keyPath(title) in this proposal.

And we also had:

#define KeyPath(...) \
DMMakeKeyPath(__VA_ARGS__, nil)

NSString *DMMakeKeyPath(NSString *firstKey, ...)
{
NSMutableArray *keyArray = [NSMutableArray arrayWithObject:firstKey];
va_list varargs;
va_start(varargs, firstKey);
NSString *nextKey = nil;
while ((nextKey = va_arg(varargs, __unsafe_unretained NSString *)))
[keyArray addObject:nextKey];
va_end(varargs);
return [keyArray componentsJoinedByString:@"."];
}

So we could make paths.

But this whole system was ugly as heck to read and required to you use ugly 
macros when defining properties AND when making key paths, so I wouldn’t use it 
again if I had to do it all again. I’d just like to demonstrate crazy lengths 
people have gone to to get SOME of this functionality.

—

I am curious how this proposal integrates with “KVO2.” Not that we’re talking 
about that here, but it’s something I imagine Apple is thinking about, so I’m 
not sure how much value my opinion is without knowing what’s coming.

(As an aside, gosh it’d be nice if other groups writing APIs had such a 
wonderful review process like the Swift group.)


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

I think so. Swift is about safety, and this make key paths much safer. And more 
readable as key paths instead of as strings.


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

The horrifying one we wrote was much inferior yet we shipped a hundred thousand 
lines or so on it.


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

Quick reading. I’m not sure if everything in it is actually implementable and I 
don’t really care what the syntax is, I just want a way to do this cleanly.



Your pal,
-Wil

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

[swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

Hi all,

Optional protocol requirements in Swift have the restriction that they only 
work in @objc protocols, a topic that’s come up a number 
 of times 
. 
The start of these threads imply that optional requirements should be available 
for all protocols in Swift. While this direction is implementable, each time 
this is discussed there is significant feedback that optional requirements are 
not a feature we want in Swift. They overlap almost completely with default 
implementations of protocol requirements, which is a more general feature, and 
people seem to feel that designs based around default implementations and 
refactoring of protocol hierarchies are overall better.

The main concern with removing optional requirements from Swift is their impact 
on Cocoa: Objective-C protocols, especially for delegates and data sources, 
make heavy use of optional requirements. Moreover, there are no default 
implementations for any of these optional requirements: each caller effectively 
checks for the presence of the method explicitly, and implements its own logic 
if the method isn’t there.

A Non-Workable Solution: Import as optional property requirements
One suggestion that’s come up to map an optional requirement to a property with 
optional type, were “nil” indicates that the requirement was not satisfied. For 
example, 

@protocol NSTableViewDelegate
@optional
- (nullable NSView *)tableView:(NSTableView *)tableView 
viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row;
- (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row;
@end

currently comes in as

@objc protocol NSTableViewDelegate {
  optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) -> 
NSView?
  optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
}

would come in as:

@objc protocol NSTableViewDelegate {
  var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) -> NSView?)? 
{ get }
  var tableView: ((NSTableView, heightOfRow: Int) -> CGFloat)? { get }
}

with a default implementation of “nil” for each. However, this isn’t practical 
for a number of reasons:

a) We would end up overloading the property name “tableView” a couple dozen 
times, which doesn’t actually work.

b) You can no longer refer to the member with a compound name, e.g., 
“delegate.tableView(_:viewFor:row:)” no longer works, because the name of the 
property is “tableView”.

c) Implementers of the protocol now need to provide a read-only property that 
returns a closure. So instead of

class MyDelegate : NSTableViewDelegate {
  func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) -> NSView? { 
… }
}

one would have to write something like

class MyDelegate : NSTableViewDelegate {
  var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) -> NSView?)? 
= {
… except you can’t refer to self in here unless you make it lazy ...
  }
}

d) We’ve seriously considered eliminating argument labels on function types, 
because they’re a complexity in the type system that doesn’t serve much of a 
purpose.

One could perhaps work around (a), (b), and (d) by allowing compound 
(function-like) names like tableView(_:viewFor:row:) for properties, and work 
around (c) by allowing a method to satisfy the requirement for a read-only 
property, but at this point you’ve invented more language hacks than the 
existing @objc-only optional requirements. So, I don’t think there is a 
solution here.

Proposed Solution: Caller-side default implementations

Default implementations and optional requirements differ most on the caller 
side. For example, let’s use NSTableView delegate as it’s imported today:

func useDelegate(delegate: NSTableViewDelegate) {
  if let getView = delegate.tableView(_:viewFor:row:) { // since the 
requirement is optional, a reference to the method produces a value of optional 
function type
// I can call getView here
  }

  if let getHeight = delegate.tableView(_:heightOfRow:) {
// I can call getHeight here
  }
}

With my proposal, we’d have some compiler-synthesized attribute (let’s call it 
@__caller_default_implementation) that gets places on Objective-C optional 
requirements when they get imported, e.g.,

@objc protocol NSTableViewDelegate {
  @__caller_default_implementation func tableView(_: NSTableView, viewFor: 
NSTableColumn, row: Int) -> NSView?
  @__caller_default_implementation func tableView(_: NSTableView, heightOfRow: 
Int) -> CGFloat
}

And “optional” disappears from the language. Now, there’s no optionality left, 
so our useDelegate example tries to just do correct calls:

func useDelegate(delegate: NSTableViewDelegate) -> NSView? {
  let view = delegate.tableView(tableView, viewFor: column, row: row)
  let height = delegate.tableView(tableView, heightOfRow: row)
}

Of course, the code above will fail if the 

[swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[David P Grove via swift-evolution]

> On Apr 5, 2016, at 5:57 PM, Kevin Lundberg via swift-evolution <
swift-evolution at swift.org> wrote:
>
> Generally I'm +1 on this, but I do have a concern. It's not made explicit
in the proposal, but I presume that this is meant to only be available on
Darwin, and not Linux or other platforms that don't have swift using the
Objective-C runtime? (Please correct me if I am mistaken.)
>
> I ask because of the swift-corelibs-foundation project; Presumably once
that is complete for Swift 3, code that makes use of this type bridging
should be able to be run cross-platform. For example:
>
> var a = [AnyObject]()
> (a as NSArray).addObject(NSObject()) // should this work on all
platforms?
>
> swift-corelibs-foundation uses its own protocol named
_ObjectTypeBridgeable (defined here:
https://github.com/apple/swift-corelibs-foundation/blob/338f4bf3a89c75a0420b49f5701466e106af02b5/Foundation/NSSwiftRuntime.swift#L205
 <
https://github.com/apple/swift-corelibs-foundation/blob/338f4bf3a89c75a0420b49f5701466e106af02b5/Foundation/NSSwiftRuntime.swift#L205
>) to simulate what happens today on Darwin platforms, but there is no
language support for it so API consumers must explicitly call its bridging
methods. It would be great if corelibs-foundation (and any code designed to
work on Linux) could take advantage of this proposal to provide the
language support, and if the proposal as written is not intended to have an
effect on Linux at all, then I would suggest we modify it so that the
resulting implementation is not tied to Objective-C and Darwin only.
>
> -Kevin
>

This is a very timely observation.  Following a suggestion from Tony
Parker, I've prototyped using (abusing?) ObjectiveCBridgeable to enable
this kind of conversion for swift-corelibs-foundation on Linux (where there
is no Objective-C runtime).  The motivation is to get consistent
cross-platform bridging.

On the plus side, the change is pretty straightforward and seems to be
working as expected (still working through all the TestFoundation test
cases and replacing bridge() calls with as operations).  I expect to
complete the initial pass through the foundation test cases by the weekend.

On the minus side, the name becomes a little misleading.  We are really
using ObjectCBridgeable to bridge from one Swift type to another Swift
type.

For the curious, the relevant pull requests are:
https://github.com/apple/swift/pull/1994
https://github.com/apple/swift-corelibs-foundation/pull/303

Would be interested in comments on the approach.

regards,

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0064: Referencing the Objective-C selector of property getters and setters

[Michael Buckley via swift-evolution]

> What is your evaluation of the proposal?

+1

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

Yes, with reservations. The proposal itself mentions that this may be a
temporary solution, and while I believe temporary solutions tend to add
more complexity over the long-term, and tend to end up being
not-so-temporary, I think interfacing well with Objective-C in a type safe
manner is important.

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

Yes, I would consider this to be a natural extension of SE-0022. In fact, I
think SE-0022 isn't really complete without this.

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

There are two ways to think of this feature: As a worse alternative to
lenses, and as a more type-safe mechanism for interoperating with
Objective-C.

The proposal already covers the first, acknowledging that lenses are
out-of-scope for Swift 3.

As for the second, I have used other languages with Objective-C bridges,
and all of them dealt with this problem by simply using foo for the getter,
and setFoo: for the setter. This approach has the advantage over SE-0064 of
not requiring any additional overloads, and I'm not quite sure why SE-0022
wasn't just implemented this way to begin with. Because it keeps the
language simpler, I probably would have advocated for this approach, but I
don't think the impact is particularly large, and since SE-0064 is already
at the proposal stage, it's probably just water under the bridge at this
point.

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

I read through the proposal and the previous two threads, and thought about
it for a few minutes.

On Thu, Apr 7, 2016 at 1:57 PM, Douglas Gregor  wrote:

> Hello Swift community,
>
> The review of SE-0064 "Referencing the Objective-C selector of property
> getters and setters" begins now and runs through April 12, 2016. The
> proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.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/0064-property-selectors.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-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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Xiaodi Wu via swift-evolution]

If we're going to bikeshed again: how about "assign"?

On Thu, Apr 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution <
swift-evolution@swift.org> wrote:

> replaceWith* is also my favourite here (same for *InPlace). Sure, it might
> be verbose, but the semantics is very clear and seems apply to a wide range
> of relevant situations. In the end, there are hundreds if not more messages
> in this (and related) threads and i am sure that you guys spent even more
> time in meetings talking about this. If I understand correctly, Swifts goal
> is clarity over laconicity. If finding sensible laconic terminology turns
> out to be surprisingly difficult, a more verbose one might be a better
> choice after all.
>
> — Taras
>
>
> > On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > on Mon Apr 04 2016, Brent Royal-Gordon 
> wrote:
> >
> >>> Indeed, OED points out that modern usage is "chiefly military."
> Probably an argument against its usage here.
> >>
> >> It seems to me that what you're sort of saying is "replaceWith", but
> >> that's kind of a mouthful.
> >
> > It's at least very explicit.  We did consider that, and chose “form” as
> > a more reasonable convention.  However, we weren't thinking of the
> > “from” problem.  I prefer “replaceWith” over “become” for some reason I
> > can't identify.
> >
> >> A quick thesaurus check suggests that the only decent single-world
> >> alternative would be "substitute", but that sounds like a regex
> >> operation. I think this is a dead end.
> >
> > --
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

Conceptually, maybe? But of course the sequence is lazily evaluated, so the
only state stored in an instance of StrideTo is one value for the current
iteration; all the other properties in a StrideTo are just the inputs to
the stride function, and no length is computed let alone stored. I get that
you want something that represents the input instead of the output, but
what do you gain from that type not achievable otherwise?
On Thu, Apr 7, 2016 at 6:59 PM Brent Royal-Gordon 
wrote:

> > I'm confused. There is an instance owning the start and end. It's called
> StrideTo or StrideThrough, conforms to Sequence (with a FIXME comment that
> it should conform to Collection) and is distinct from Range and from the
> Strideable bounds themselves. Is that different from what you're describing?
>
> Yes, it is different. StrideTo and StrideThrough represent the sequence
> resulting from the striding operation. If there was only one of them, you
> would probably call it StrideSequence. They are the *result* of the
> `stride` function or `striding` method.
>
> What I'm talking about is a single instance which represents what you are
> striding *over*, but *not* the length of the stride. It is an *input* to
> the `stride` function or `striding` method.
>
> Does that make sense?
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Taras Zakharko via swift-evolution]

replaceWith* is also my favourite here (same for *InPlace). Sure, it might be 
verbose, but the semantics is very clear and seems apply to a wide range of 
relevant situations. In the end, there are hundreds if not more messages in 
this (and related) threads and i am sure that you guys spent even more time in 
meetings talking about this. If I understand correctly, Swifts goal is clarity 
over laconicity. If finding sensible laconic terminology turns out to be 
surprisingly difficult, a more verbose one might be a better choice after all. 

— Taras


> On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Apr 04 2016, Brent Royal-Gordon  wrote:
> 
>>> Indeed, OED points out that modern usage is "chiefly military." Probably an 
>>> argument against its usage here.
>> 
>> It seems to me that what you're sort of saying is "replaceWith", but
>> that's kind of a mouthful. 
> 
> It's at least very explicit.  We did consider that, and chose “form” as
> a more reasonable convention.  However, we weren't thinking of the
> “from” problem.  I prefer “replaceWith” over “become” for some reason I
> can't identify.
> 
>> A quick thesaurus check suggests that the only decent single-world
>> alternative would be "substitute", but that sounds like a regex
>> operation. I think this is a dead end.
> 
> -- 
> 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] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

I'm confused. There is an instance owning the start and end. It's called
StrideTo or StrideThrough, conforms to Sequence (with a FIXME comment that
it should conform to Collection) and is distinct from Range and from the
Strideable bounds themselves. Is that different from what you're describing?

If I'm not misunderstanding, you're asking for a protocol common to
StrideTo and StrideThrough to which other types such as a hypothetical
NSDateStride could conform?

On Thu, Apr 7, 2016 at 5:25 PM Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> >> Actually, it would need to be something like
> >> `calendar[startDate.. >> NSCalendarUnit is not itself a stride, it is the *unit* of the
> >> stride.
> >
> > Maybe:
> >
> >  calendar.days[startDate..
> I've been leaning towards parameters for additional flexibility, but the
> difference there is only slightly more than bikeshedding.
>
> > However, it doesn't explain why
> >
> >  calendar[startDate.. >
> > “doesn't quite help.”  It seems to me that
> >
> >  calendar[startDate.. >
> > does factor in the calendar and unit.
>
> Yes, it does—as long as Strideable changes so that the instance created by
> this expression participates in the striding. My point is that, as long as
> the operations in Strideable are performed on one of the two strides, the
> "range" we're moving over can't be involved enough to help. Striding has to
> be done with the assistance of the instance owning the start and end, not
> just the start and end themselves.
>
> Basically, what I'm saying is that Strideable needs a redesign along the
> lines of the indexing system. We redesigned indexing so that the collection
> manipulates the indexes, rather than the indexes manipulating themselves,
> because the indexes don't always have enough information to do the job. We
> need to do the same thing with Strideable.
>
> >> For example, suppose you modify `Strideable` so that, instead of
> >> applying to the values participating in the striding, it applies to
> >> the instance containing those values:
> >>
> >>  public protocol Strideable {
> >>  associatedtype Element: Comparable
> >>  associatedtype Stride: SignedNumber
> >>
> >>  var start: Value
> >>  var end: Value
> >>
> >>  public func distance(from earlier: Element, to later:
> Element) -> Stride
> >>  public func advance(element: Element, by stride: Stride)
> -> Element
> >>  }
> >
> > Presumably you mean for Strideable to have a striding(by:_) method as
> well?
>
> Yes, there would be an extension method like that (or there would be a
> `func stride(over: StrideableType, by:
> StrideableType.Stride) -> …`, which is the same thing). I didn't include it
> because it's not a requirement imposed on the conforming type.
>
> > If so, how is this fundamentally different from Collection?  Shouldn't
> > every Collection support this?
>
> Huh, interesting. Very, very interesting.
>
> Strideable is more widely applicable than Collection; for instance, a
> Range can't be a Collection (except via `nextafter`), but it is
> Strideable. But every RandomAccessCollection can be Strideable. (So could
> any BidirectionalCollection, for that matter, although it would be slower.)
> `array.striding(by: 2)` is a coherent and useful operation.
>
> So yes, I think every Collection (with a suitable index) could be
> Strideable. But there are Strideable things which aren't collections.
>
> > Except we don't have that capability today.  Instead we'd be using
> > overloads of ..< and ... to produce more-capable range types, c.f.
> >
> https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Range.swift#L504
> >
> https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Range.swift#L519
>
> That works too, I suppose. You would end up with a StrideableRange
> "between" your current CountableRange (which is a Collection) and Range
> (which is a glorified tuple).
>
> --
> 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

Re: [swift-evolution] Feature proposal: Range operator with step

[Brent Royal-Gordon via swift-evolution]

>> Actually, it would need to be something like
>> `calendar[startDate..> NSCalendarUnit is not itself a stride, it is the *unit* of the
>> stride. 
> 
> Maybe:
> 
>  calendar.days[startDate.. However, it doesn't explain why
> 
>  calendar[startDate.. 
> “doesn't quite help.”  It seems to me that 
> 
>  calendar[startDate.. 
> does factor in the calendar and unit.

Yes, it does—as long as Strideable changes so that the instance created by this 
expression participates in the striding. My point is that, as long as the 
operations in Strideable are performed on one of the two strides, the "range" 
we're moving over can't be involved enough to help. Striding has to be done 
with the assistance of the instance owning the start and end, not just the 
start and end themselves.

Basically, what I'm saying is that Strideable needs a redesign along the lines 
of the indexing system. We redesigned indexing so that the collection 
manipulates the indexes, rather than the indexes manipulating themselves, 
because the indexes don't always have enough information to do the job. We need 
to do the same thing with Strideable.

>> For example, suppose you modify `Strideable` so that, instead of
>> applying to the values participating in the striding, it applies to
>> the instance containing those values:
>> 
>>  public protocol Strideable {
>>  associatedtype Element: Comparable
>>  associatedtype Stride: SignedNumber
>> 
>>  var start: Value
>>  var end: Value
>> 
>>  public func distance(from earlier: Element, to later: Element) 
>> -> Stride
>>  public func advance(element: Element, by stride: Stride) -> 
>> Element
>>  }
> 
> Presumably you mean for Strideable to have a striding(by:_) method as well?

Yes, there would be an extension method like that (or there would be a `func 
stride(over: StrideableType, by: 
StrideableType.Stride) -> …`, which is the same thing). I didn't include it 
because it's not a requirement imposed on the conforming type.

> If so, how is this fundamentally different from Collection?  Shouldn't
> every Collection support this?

Huh, interesting. Very, very interesting.

Strideable is more widely applicable than Collection; for instance, a 
Range can't be a Collection (except via `nextafter`), but it is 
Strideable. But every RandomAccessCollection can be Strideable. (So could any 
BidirectionalCollection, for that matter, although it would be slower.) 
`array.striding(by: 2)` is a coherent and useful operation.

So yes, I think every Collection (with a suitable index) could be Strideable. 
But there are Strideable things which aren't collections.

> Except we don't have that capability today.  Instead we'd be using
> overloads of ..< and ... to produce more-capable range types, c.f.  
> https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Range.swift#L504
> https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Range.swift#L519

That works too, I suppose. You would end up with a StrideableRange "between" 
your current CountableRange (which is a Collection) and Range (which is a 
glorified tuple).

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [Review] SE-0064: Referencing the Objective-C selector of property getters and setters

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0064 "Referencing the Objective-C selector of property getters 
and setters" begins now and runs through April 12, 2016. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.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/0064-property-selectors.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] [Review] SE-0063: SwiftPM System Module Search Paths

[Anders Bertelrud via swift-evolution]

Hello Swift community,

A review of "SwiftPM System Module Search Paths" for the Swift Package Manager 
begins now and runs through Wednesday, April 13th.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:

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

or, if you would like to keep your feedback private, directly to the review 
manager.

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 the Swift Package Manager?
* Does this proposal fit well with the feel and direction of the Swift 
Package Manager?
* If you have you used other package managers 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,

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

[swift-evolution] Ability to pack, order and align certain types of Structs (like in C)

[hitstergtd+swiftevo--- via swift-evolution]

To the community:

Neither am I a compiler/language design expert nor have I previously
written a proposal to that effect, so I apologise if I have
trivialised the matter especially with regard to other parts of Swift
or if some of it already exists. I am also aware that what I've
proposed herein maybe possible through alternate means. However, the
aim of this is to make it a first-class feature in Swift itself. For
those unfamiliar with what is being requested, please see [2], [5] and [8].

I have also filed this as a language feature request at [7].

Proposal:
* As a Swift language user, I would like the ability to specify
packing, order and alignment for certain type of Structs and their
members.
* The characteristics requested are: packing, padding, ordering and
byte-level alignment of Struct elements
* All the requested characteristics would work similarly to the way they do in C
* Ideally, this should be achieved in a way that makes it simple to
use with appropriate syntactic sugar

Potential Preconditions (for the feature):
* Only Structs with certain, basic named types such as Int, UInt, etc.?
* Allow Enums and Tuples as well, so long as only basic named types
are allowed within them?
* No other nested types unless they meet the above criteria?
* Type aliased names can be used within the Struct so long as they
meet the above preconditions?

Alternatives:
* Augment and integrate something similar to [1], which mimics the
Python struct module [6]
* Recommend interfacing with C, for any language user who requires the
aforementioned characteristics; but this route would devoid the
language of self-sufficiency from a systems programming aspect.

Ultimately even if the above is deemed totally undesirable (I hope
not), at the very least, I hope it stirs discussion about being able
to use Swift as a systems programming language and how we could
possibly move toward that direction.

Thanks for your consideration!

For reference:

[1] https://github.com/nst/BinUtils/
[2] 
http://stackoverflow.com/questions/24139149/how-do-i-create-a-packed-data-structure-in-swift
[3] 
http://stackoverflow.com/questions/13688625/how-to-declare-packed-struct-without-padding-for-llvm
[4] 
https://llvm.org/svn/llvm-project/cfe/branches/eh-experiment/test/Sema/struct-packed-align.c
[5] http://www.catb.org/esr/structure-packing/
[6] https://docs.python.org/3/library/struct.html
[7] https://bugs.swift.org/browse/SR-1134
[8] 
https://mikeash.com/pyblog/friday-qa-2014-08-01-exploring-swift-memory-layout-part-ii.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

Hi All.

nearly no one has yet reacted on my mail, echoed here again,

which leaves by me the following questions pending:

-does what I define and describe completely cover all the required functionality
 for ranges for all numerical types?

-does it eliminate the need for using “Stride(...)”  at least for numerical 
scalars?

-combined with for .. in…  , is it an adequate replacement for the  classical 
for loop?

-can we eliminate  half open operators? Because imho that would simplify things 
greatly.
  -to which text of Dijkstra is this related?  


Objections? 
improvements? 
Things that I have missed? 
Feasibility? 
Implementable?

Thanks
TedvG





> On 06.04.2016, at 22:43, Ted F.A. van Gaalen  wrote:
> 
> 
> 
> Hi Erica, Dave
> 
> Based on what I’ve (not all) read under this topic: 
> 
> I’d suggest a more complete approach:
> 
> Ranges should support:  (as yet not implemented) 
> 
> - All numerical data types (Double, Float, Int, Money***, Decimal*** ) 
> - An arbitrary increment or decrement value.
> - Working in the complete  - + numerical range
> - Allow traversing in both   - + directions.
> 
> 
> 
> The basics:
> 
> (v1…v2).by(v3) // this still is readable. and can be optimized by the 
> compiler (predictable sequence)
> 
> Rules:
> 
> v1, v2, v3  are any numerical type scalar type  
> v1, v2, v3  must have the same numerical type.
> v1 >  v2:   is allowed and correctly evaluated.  e.g. 
> (8.0…-3.14159).by(-0.0001) 
> 
> 
> The  ..<  half open operator is no longer allowed.   write e.g.   
> 0...ar.count - 1
> 
> "by(…)”  is obligatory with floating point range.
> 
>the default “by(…)” value of 1 makes sense only with integer 
> ranges.
> 
> 
> valid examples:
> (5…9)// 5 6 7 8 9 Integer range without “by” 
> defaults to 1 as increment value.
> (1...10).by(2) // 1 3 5 7 9.
> (2...10).by(2) // 2 4 6 8 10.
> (4…-4).by(-2) // 4  2 0 -2 -4 .// runs backwards  
> <<<
> (30..-10).by(-2)// 30 28 26 24 22 ….. -10.
> (10...0).by(-3)  // 10 7 4 1. 
> 
> (12…-10) // is valid, but returns empty because default 
> increment value = 1
> 
> (12.0…-12.0).by(-1.5)   // 12.0  10.5  9.0….  // of course 
> with float imprecision
>
>
> 
>invalid examples:
> 
>(23.0..<60.5).by(0.5) // half open ranges are no  longer allowed 
> ** 
>   (23.0…60.5) // “ by"  is obligatory with floats.
>   (14...8).by(0.5)//  v1 v2 and v3 don’t have the same 
> numerical type 
> 
> 
> Half open ranges make no real sense (are not really useful) with floating 
> point values.
> and no sense at all with e.g (12..<-1)  afaics 
> 
> 
> At least for float iterations the increment value should not each time be 
> accumulated like
> v1 += v3;  v1 += v3;  v1 += v3;  ….   // causes float 
> number drift.
> but be freshly multiplied with each iteration, e.g. by using an internal 
> iteration counter
> like so:
> 
> v = v1 + v3 * i++; v = v1 + v3 * i++;  v = v1 + v3 * i++;  v = v1 + 
> v3 * i++; <<<
> 
> for reasons of precision.
> 
> If one has worked with floating point data more often
> awareness of its precision limitations become a second nature conscience. 
> E.g. it is perfectly acceptable and known (also in classical for-loops) that
> (0.0…1.0).by(0.1) is not guaranteed to reach the humanly expected value of 
> 1.0.
> This is normal. Due to the nature of what mostly is done in the
> floating point numbers domain, this does not often cause a problem
> (e.g like working with a slide ruler) 
> if it is important to reach the “expected end” then one could
> -add an epsilon value like so (v1…v2 + 0.1) 
> -generate the desired float sequence within an integer loop.
> 
> 
> The above “range” (imho) improvement makes the 
> stride.. function/keyword completely unnecessary.
> 
> Due to its ability to process reversed ranges as is, 
> the .reverse() is optional (no longer necessary in most cases,
> allowing the compiler to optimize without having to process 
> it like a collection.
> 
> 
> Now that we have a fully functional range, which can do all things desired, 
> one can
> then of course, pass this range without any change  to a collection based for 
> …  e.g.
> 
> for v in (v1…v2).by(v3)   // optionally add other collection 
> operators/filters/sorts here
> 
> (or in any other construct you might see fit)
>
> 
> This seems to be a reasonable alternative for
> 
> - the classical for ;; loop
> -the collection-free for-loop  
>  for v from v1 to v2 by v3
> 
> As you know, the latter is what I have been suggesting, 
> but seemingly does not find much support,
> 

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[David Waite via swift-evolution]

In the sense that these are existing terms of art from functional programming, 
they inherit the meaning of being non-mutating.

If we did consider changing the name of one, I’d prefer if we considered all of 
them at once (so the various bike sheds would be painted in complementary 
colors)

-DW

> On Apr 7, 2016, at 12:12 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Thu Apr 07 2016, Arsen Gasparyan  wrote:
> 
>> Hey guys,
>> 
>> The 'flatten()' method didn't get the Swift 3 API renaming treatment it 
>> should
>> have, to go along with reversed, sorted, joined, etc.
>> As I see Dmitri Gribenko already agree with it but we still have to discuss 
>> it
>> here. So what do you think?
>> 
>> Implementation: https://github.com/apple/swift/pull/2038
> 
> I am agnostic on this, but should explain the rationale for the current
> name. It wasn't overlooked.  We kept flatten as is because it is part of
> a suite of methods that are terms of art from functional programming
> (map, filter, flatMap, reduce) that don't follow the naming guidelines
> but we are nonetheless leaving alone.  The fact that the semantics of
> flatMap can only be sensibly described in terms of map and flatten
> reinforces this rationale.
> 
> If we want to change flatten, we should decide whether this is a
> principled change, and if so, what the principle is.  If it's a change
> simply because “flatten() feels weird,” that's OK too, but we should
> understand what we're doing and why.
> 
> -- 
> 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] [Proposal] Invert the order of pattern match operator

[David Rodrigues via swift-evolution]

> On 07 Apr 2016, at 19:16, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> It would be nice to know the rationale behind the choice of the current 
>> syntax.
>> I agree that these seem more natural:
>> 
>>@warn_unused_result
>>public func ~=(value: I, 
>> pattern:
>>Range) -> Bool
>> 
>>@warn_unused_result
>>public func ~=(value: I.Bound, pattern: I) -> Bool
> 
> +1

This operator was firstly introduced in Swift in the form =~ but then it was 
reversed to the current form (~3y ago). There’s a little context about this 
change on Twitter: https://twitter.com/dmcrodrigues/status/717063623957471232 
.

>> I would not change from `~=` to `=~` though.
> 
> One downside with `~=` is that it reads like `+=`, which mutates the
> LHS.  Of course, `=~` has its own issues, e.g. `x=~y` might read as `x =
> ~y`.

I agree but this operator already exists in other languages like Ruby and Perl, 
so align the syntax may be a good option.

> On 07 Apr 2016, at 18:56, Erica Sadun  wrote:
> 
> I'd prefer to offer both ~= and =~, allowing the consumer to choose which 
> side the pattern sits on.

On the other hand, I like in particular the option of having both `~=` and `=~` 
to provide more flexibility like Erica has suggested. The main question is if 
that’s ok introduce another operator in the language.

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

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Dmitri Gribenko via swift-evolution]

On Thu, Apr 7, 2016 at 11:27 AM, Vladimir.S  wrote:
> OK, thank you for the clarification Dmitri.
> If these methods are going away - no possible problems :-)
> Will we have some kind of .next() method for integers in new indexing model
> and in Swift 3.0 in general?

There would be no need to.  Collection will have a .successor(of:)
method that returns the next index after the given one.

> (But actually I don't agree that there is all OK with these functions in
> current version of Swift. "Not designed" - understand, but they can be
> used(so they will! be used) "out of the box", even Int8 has these methods,
> Int32.max is just 2GB for [Int8] etc..
> Yes, in case of using successor() only with Int64 only for indices of Array
> - all looks like OK.)

I can see that, but when you know that you are dealing with an
integer, isn't "+ 1" a more common and readable notation?

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Vladimir.S via swift-evolution]

OK, thank you for the clarification Dmitri.
If these methods are going away - no possible problems :-)
Will we have some kind of .next() method for integers in new indexing model 
and in Swift 3.0 in general?



(But actually I don't agree that there is all OK with these functions in 
current version of Swift. "Not designed" - understand, but they can be 
used(so they will! be used) "out of the box", even Int8 has these methods,

Int32.max is just 2GB for [Int8] etc..
Yes, in case of using successor() only with Int64 only for indices of Array 
- all looks like OK.)



On 07.04.2016 20:54, Dmitri Gribenko wrote:

This was done for performance reasons.  Array's indices are Ints, and
adding an overflow check here was causing significant performance
issues when iterating over arrays.  These methods were not designed to
be used in contexts other than indices.  When ints are used as
indices, doing an overflow check in successor() does not prevent any
mistakes, since Array's bounds are always tighter than
Int.min...Int.max.

These methods are going away in the new indexing model.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011552.html

Dmitri

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

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

[Dave Abrahams via swift-evolution]

on Thu Apr 07 2016, David Owens II  wrote:

> It would be nice to know the rationale behind the choice of the current 
> syntax.
> I agree that these seem more natural:
>
> @warn_unused_result
> public func ~=(value: I, 
> pattern:
> Range) -> Bool
>
> @warn_unused_result
> public func ~=(value: I.Bound, pattern: I) -> Bool

+1

> I would not change from `~=` to `=~` though.

One downside with `~=` is that it reads like `+=`, which mutates the
LHS.  Of course, `=~` has its own issues, e.g. `x=~y` might read as `x =
~y`.

> So you have this:
>
> let x = 4
>
> switch x {
> case let v where x ~= 0...5: print("matched: \(v)")
> default: print("nothing!!")
> }
>
> -David
>
> On Apr 7, 2016, at 4:57 AM, David Rodrigues via swift-evolution
>  wrote:
>
> Hi all,
>
> Swift has a pattern match operator, ~=, which is unknown to many (like me
> until a few weeks ago), that performs a match between a value and a 
> certain
> pattern, e.g. checking if an integer value is contained in a range of
> integers.
>
> This operator may be little known, but it plays a key role in the language
> since it's used behind the scenes to support expression patterns in 
> `switch
> ` statement case labels, which we all know are extremely popular.
>
> let point = (2, 4)
> switch point {
> case (0, 0):
> print("The point is at the origin")
> case (0...4, 0...4):
> print("The point is in the subregion")
> default:
> break
> }
>
> Most of the time we don't use the operator directly but it is available 
> and
> can be handy in certain conditions.
>
> let point = (2, 4)
> switch point {
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y:
> print("The point is in the subregion")
> default:
> break
> }
>
> However the current syntax is not ideal (in my opinion). We're not really
> declaring the operation that we want to do, and that has an impact in the
> expressivity and readability of the code. Currently we're doing matches 
> like
> "if blue is the ocean" instead of "if the ocean is blue" or "if the ocean
> contains the whale" instead of "if the whale is in the ocean".
>
> For that reason, I would like to suggest inverting the order of the 
> operator
> to match more closely our logical thought.
>
> case (let x, let y) where x =~ 0...4 && y =~ 0...4: // Proposed
> // vs
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y: // Current
>
> I have an ongoing proposal to suggest this change and it contains a little
> more context. It is available here: 
>
> 
> https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/-invert-order-of-pattern-match-operator.md
>.
>
> Any feedback is very welcome.
>
> Thank you.
>
> David Rodrigues
> ___
> 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

-- 
Dave

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

Re: [swift-evolution] Missing initializers from/to FloatingPointType

[Stephen Canon via swift-evolution]

The draft proposal may be easier reading:

https://github.com/stephentyrone/swift-evolution/blob/master/-floating-point-protocols.md

> On Apr 7, 2016, at 11:16 AM, Max Moiseev via swift-evolution 
>  wrote:
> 
> Hi Dan,
> 
> New protocols are in the making for both integers and floating point numbers.
> 
> You particular problem is addressed here: 
> https://github.com/stephentyrone/swift/commits/floating-point-revision 
> 
> 
> max
> 
>> On Mar 30, 2016, at 6:36 AM, Dan Raviv via swift-evolution 
>> > wrote:
>> 
>> While FloatingPointType can be initialized from various Int type variants, 
>> it seems to be missing an initializer from Double/Float. Similarly, there 
>> are no initializers from FloatingPointType to Double/Float. Is this 
>> intentional?
>> 
>> I've tried implementing the following:
>> 
>> // https://en.wikipedia.org/wiki/Window_function#Tukey_window 
>> 
>> public func tukeyWindowFunc(index: Int, N: Int) -> Double {
>> let L = N/8
>> let indexAbs = min(index, N-1-index)
>> if indexAbs >= L {
>> return 1.0
>> }
>> else {
>> let r = Double(indexAbs) / Double(L)
>> return 0.5*(1.0 + cos(M_PI * (r - 1.0)))
>> }
>> }
>> 
>> extension Array where Element: FloatingPointType {
>> public func tukeyWindowArray() -> [Element] {
>> return (0..> }
>> }
>> 
>> The extension failed to compile no matter how I spun it, since Double and 
>> FloatingPointType can't multiply each other and neither type can be cast to 
>> the other.
>> 
>> I would settle for extending just Array, but that isn't supported 
>> yet either ;)
>> 
>> Cheers,
>> Dan
>> ___
>> 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] Missing initializers from/to FloatingPointType

[Max Moiseev via swift-evolution]

Hi Dan,

New protocols are in the making for both integers and floating point numbers.

You particular problem is addressed here: 
https://github.com/stephentyrone/swift/commits/floating-point-revision

max

> On Mar 30, 2016, at 6:36 AM, Dan Raviv via swift-evolution 
>  wrote:
> 
> While FloatingPointType can be initialized from various Int type variants, it 
> seems to be missing an initializer from Double/Float. Similarly, there are no 
> initializers from FloatingPointType to Double/Float. Is this intentional?
> 
> I've tried implementing the following:
> 
> // https://en.wikipedia.org/wiki/Window_function#Tukey_window 
> 
> public func tukeyWindowFunc(index: Int, N: Int) -> Double {
> let L = N/8
> let indexAbs = min(index, N-1-index)
> if indexAbs >= L {
> return 1.0
> }
> else {
> let r = Double(indexAbs) / Double(L)
> return 0.5*(1.0 + cos(M_PI * (r - 1.0)))
> }
> }
> 
> extension Array where Element: FloatingPointType {
> public func tukeyWindowArray() -> [Element] {
> return (0.. }
> }
> 
> The extension failed to compile no matter how I spun it, since Double and 
> FloatingPointType can't multiply each other and neither type can be cast to 
> the other.
> 
> I would settle for extending just Array, but that isn't supported yet 
> either ;)
> 
> Cheers,
> Dan
> ___
> 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] [SR-933] Rename flatten to flattened

[Dave Abrahams via swift-evolution]

on Thu Apr 07 2016, Arsen Gasparyan  wrote:

> Hey guys,
>
> The 'flatten()' method didn't get the Swift 3 API renaming treatment it should
> have, to go along with reversed, sorted, joined, etc.
> As I see Dmitri Gribenko already agree with it but we still have to discuss it
> here. So what do you think?
>
> Implementation: https://github.com/apple/swift/pull/2038

I am agnostic on this, but should explain the rationale for the current
name. It wasn't overlooked.  We kept flatten as is because it is part of
a suite of methods that are terms of art from functional programming
(map, filter, flatMap, reduce) that don't follow the naming guidelines
but we are nonetheless leaving alone.  The fact that the semantics of
flatMap can only be sensibly described in terms of map and flatten
reinforces this rationale.

If we want to change flatten, we should decide whether this is a
principled change, and if so, what the principle is.  If it's a change
simply because “flatten() feels weird,” that's OK too, but we should
understand what we're doing and why.

-- 
Dave

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

Re: [swift-evolution] divisible-by operator

[Milos Rankovic via swift-evolution]

Thank you for giving this a thought!

milos

> On 7 Apr 2016, at 15:13, Erica Sadun  wrote:
> 
>> 
>> On Apr 6, 2016, at 10:13 AM, Milos Rankovic via swift-evolution 
>> > wrote:
>> 
>> Checking for divisibility is very common:
>> 
>> 21 % 3 == 0 // true
>> 
>> In fact, this is such a common use of the `%` operator that the `== 0` side 
>> of the expression seems distracting in this use case. For quite a while now, 
>> I’ve been using a custom operator for this, which is steadily growing on me:
>> 
>> 21 %== 3 // true
>> 
>> … which also allows me to overload it for sequences:
>> 
>> 21 %== [7, 3] // true
>> 
>> (If I’m inadvertently misusing this mailing list to share such a minor idea, 
>> please tell me off so that I can learn not to do it again!)
>> 
> 
> While modulo checks are common, I don't think that your proposed solution 
> (%==) enhances readability or saves typing *to such extent* that it vastly 
> improves over the existing art:
> 
> 21 % 3 == 0 reads easily from left to right, is quick to type, is understood 
> across many languages.
> 
> 21 %== 3saves a few spaces, is less immediately understandable (due to 
> the visual overlap with `+=` and `-=`) and would be (as far as I'm aware of) 
> unique to Swift.
> 
> I applaud the thinking and creativity but I would not support the proposal.
> 
> -- E

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Thu Apr 07 2016, Brent Royal-Gordon  wrote:

>>> calendar.using(.Day).stride(from: startDate, to: endDate, by: 1)
>> 
>>> The `start` and `end` parameters could be grouped together into a
>>> single parameter to match `stride(over:by:)`, but you can't put the
>>> calendar or the unit into the stride—without them, there is no
>
>>> coherent way to calculate the distance between two dates.
>>> 
>>> So if some types need a strider, and will need to have the method
>>> structured as `strider.stride(something:by:)`, it seems like the
> free
>>> function version for types which *don't* need a strider ought to be
>>> `stride(something:by:)`. The `something.striding(by:)` design can't
> be
>>> easily adapted to this situation.
>> 
>>  calendar[startDate..> 
>> ?
>
> Actually, it would need to be something like
> `calendar[startDate.. NSCalendarUnit is not itself a stride, it is the *unit* of the
> stride. 

Maybe:

  calendar.days[startDate.. But even that doesn't quite help.
>
> Here's the issue.
>
> Take a look at today's Strideable. Stripped of comments and irrelevant
> annotations, you have:
>
>   protocol Strideable : Comparable {
>   associatedtype Stride : SignedNumberType
>   func distanceTo(other: Self) -> Stride
>   func advancedBy(n: Stride) -> Self
>   }
>
> The problem is that there's no good way to get the calendar and unit
> into these methods. If you package them inside `Stride`, then
> `distanceTo` has no idea what calendar or unit it's supposed to
> return. If you package them inside `Self`, then `distanceTo` has two
> calendars and two units, and they might not agree (and the type system
> can't catch this issue).
>
> To fix this, you need to have a single instance which performs the
> calculation. For simple Strideable types, this instance would not do
> very much, but for dates, it would factor in the calendar and unit.

I follow all the above; it's a good explanation of the problem.
However, it doesn't explain why

  calendar[startDate.. For example, suppose you modify `Strideable` so that, instead of
> applying to the values participating in the striding, it applies to
> the instance containing those values:
>
>   public protocol Strideable {
>   associatedtype Element: Comparable
>   associatedtype Stride: SignedNumber
>
>   var start: Value
>   var end: Value
>
>   public func distance(from earlier: Element, to later: Element) 
> -> Stride
>   public func advance(element: Element, by stride: Stride) -> 
> Element
>   }

Presumably you mean for Strideable to have a striding(by:_) method as well?

If so, how is this fundamentally different from Collection?  Shouldn't
every Collection support this?

> Now, with some *really* aggressive conditional conformance work, you
> could do this:
>
>   extension Range: Strideable where Element == Int {
>   typealias Stride = Int
>
>   public func distance(from earlier: Int, to later: Int)
> -> Int {
>   return later - earlier
>   }
>   public func advance(element: Int, by stride: Int) {
>   return value + stride
>   }
>   }
>   extension Range: Strideable where Element == Double {
>   // Ignoring the accumulation issue.
>   typealias Stride = Double
>
>   public func distance(from earlier: Int, to later: Int) -> Int {
>   return later - earlier
>   }
>   public func advance(element: Double, by stride: Double) {
>   return element + stride
>   }
>   }

Except we don't have that capability today.  Instead we'd be using
overloads of ..< and ... to produce more-capable range types, c.f.  
https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Range.swift#L504
https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Range.swift#L519

>   
>   // etc., for each type you care about.
>   // 
>   // This could be automated by creating a `RangeStrideable` protocol 
> similar to the old Strideable,
>   // and having types with this automatic behavior conform to it. You 
> could then have a single:
>   // extension Range: Strideable where Element: RangeStrideable
>
> It would not be possible to stride directly over a range of NSDates,
> but you could have a "calendar range" which could be `Strideable`,
> like so:
>
>   struct NSCalendarRange {
>   var start: NSDate
>   var end: NSDate
>
>   var calendar: NSCalendar
>   var unit: 

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

[Erica Sadun via swift-evolution]

I'd prefer to offer both ~= and =~, allowing the consumer to choose which side 
the pattern sits on.

-- E


> On Apr 7, 2016, at 11:09 AM, David Owens II via swift-evolution 
>  wrote:
> 
> It would be nice to know the rationale behind the choice of the current 
> syntax. I agree that these seem more natural:
> 
> @warn_unused_result
> public func ~=(value: I, pattern: 
> Range) -> Bool
> 
> @warn_unused_result
> public func ~=(value: I.Bound, pattern: I) -> Bool
> 
> I would not change from `~=` to `=~` though.
> 
> So you have this:
> 
> let x = 4
> 
> switch x {
> case let v where x ~= 0...5: print("matched: \(v)")
> default: print("nothing!!")
> }
> 
> -David
> 
>> On Apr 7, 2016, at 4:57 AM, David Rodrigues via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> Swift has a pattern match operator, ~=, which is unknown to many (like me 
>> until a few weeks ago), that performs a match between a value and a certain 
>> pattern, e.g. checking if an integer value is contained in a range of 
>> integers.
>> 
>> This operator may be little known, but it plays a key role in the language 
>> since it's used behind the scenes to support expression patterns in `switch` 
>> statement case labels, which we all know are extremely popular.
>> 
>> let point = (2, 4)
>> switch point {
>> case (0, 0):
>> print("The point is at the origin")
>> case (0...4, 0...4):
>> print("The point is in the subregion")
>> default:
>> break
>> }
>> 
>> Most of the time we don't use the operator directly but it is available and 
>> can be handy in certain conditions.
>> 
>> let point = (2, 4)
>> switch point {
>> case (let x, let y) where 0...4 ~= x && 0...4 ~= y:
>> print("The point is in the subregion")
>> default:
>> break
>> }
>> 
>> However the current syntax is not ideal (in my opinion). We're not really 
>> declaring the operation that we want to do, and that has an impact in the 
>> expressivity and readability of the code. Currently we're doing matches like 
>> "if blue is the ocean" instead of "if the ocean is blue" or "if the ocean 
>> contains the whale" instead of "if the whale is in the ocean".
>> 
>> For that reason, I would like to suggest inverting the order of the operator 
>> to match more closely our logical thought.
>> 
>> case (let x, let y) where x =~ 0...4 && y =~ 0...4: // Proposed
>> // vs
>> case (let x, let y) where 0...4 ~= x && 0...4 ~= y: // Current
>> 
>> I have an ongoing proposal to suggest this change and it contains a little 
>> more context. It is available here: 
>> 
>> https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/-invert-order-of-pattern-match-operator.md
>>  
>> .
>> 
>> Any feedback is very welcome.
>> 
>> Thank you.
>> 
>> David Rodrigues
>> ___
>> 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] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Dmitri Gribenko via swift-evolution]

On Thu, Apr 7, 2016 at 12:20 AM, Vladimir.S via swift-evolution
 wrote:
> But. .successor() .predecessor() methods for Int values do not follow these
> rules for overflow situations. I.e. :
> let i : Int8 = Int8.max
> let k : Int8 = i.successor()
> - is OK for current Swift compiler. We have i==127 and k==-128, no run-time
> error.

This was done for performance reasons.  Array's indices are Ints, and
adding an overflow check here was causing significant performance
issues when iterating over arrays.  These methods were not designed to
be used in contexts other than indices.  When ints are used as
indices, doing an overflow check in successor() does not prevent any
mistakes, since Array's bounds are always tighter than
Int.min...Int.max.

These methods are going away in the new indexing model.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011552.html

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Vladimir.S via swift-evolution]

This is exactly why I think successor()/predecessor() must raise runtime 
error on integer overflow - because we(I believe) expect this behavior from 
these funcs.
For example, someone, who don't know about current behavior of these 
methods, can use them to increment/decrement index for some 
collection/array and so produce hard-to-find errors or vulnerable code.


Any other opinion on this proposal please?


On 07.04.2016 14:31, Haravikk wrote:



On 7 Apr 2016, at 08:20, Vladimir.S via swift-evolution
> wrote:

(TLDR: Suggest to change successor() method for Int values to follow
default Swift rules for integer overflow. Probably some kind of
successorWithOverflow could be introduced to use when needed)


I’m a +1 for this; in fact, this is just how I assumed they worked, as the
postcondition requirement for .successor() is that n.successor() > n if I
remember right, which clearly can’t be the case if the limit of the integer
is reached, so a runtime error seems reasonable.

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

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

[David Owens II via swift-evolution]

It would be nice to know the rationale behind the choice of the current syntax. 
I agree that these seem more natural:

@warn_unused_result
public func ~=(value: I, pattern: 
Range) -> Bool

@warn_unused_result
public func ~=(value: I.Bound, pattern: I) -> Bool

I would not change from `~=` to `=~` though.

So you have this:

let x = 4

switch x {
case let v where x ~= 0...5: print("matched: \(v)")
default: print("nothing!!")
}

-David

> On Apr 7, 2016, at 4:57 AM, David Rodrigues via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Swift has a pattern match operator, ~=, which is unknown to many (like me 
> until a few weeks ago), that performs a match between a value and a certain 
> pattern, e.g. checking if an integer value is contained in a range of 
> integers.
> 
> This operator may be little known, but it plays a key role in the language 
> since it's used behind the scenes to support expression patterns in `switch` 
> statement case labels, which we all know are extremely popular.
> 
> let point = (2, 4)
> switch point {
> case (0, 0):
> print("The point is at the origin")
> case (0...4, 0...4):
> print("The point is in the subregion")
> default:
> break
> }
> 
> Most of the time we don't use the operator directly but it is available and 
> can be handy in certain conditions.
> 
> let point = (2, 4)
> switch point {
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y:
> print("The point is in the subregion")
> default:
> break
> }
> 
> However the current syntax is not ideal (in my opinion). We're not really 
> declaring the operation that we want to do, and that has an impact in the 
> expressivity and readability of the code. Currently we're doing matches like 
> "if blue is the ocean" instead of "if the ocean is blue" or "if the ocean 
> contains the whale" instead of "if the whale is in the ocean".
> 
> For that reason, I would like to suggest inverting the order of the operator 
> to match more closely our logical thought.
> 
> case (let x, let y) where x =~ 0...4 && y =~ 0...4: // Proposed
> // vs
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y: // Current
> 
> I have an ongoing proposal to suggest this change and it contains a little 
> more context. It is available here: 
> 
> https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/-invert-order-of-pattern-match-operator.md
>  
> .
> 
> Any feedback is very welcome.
> 
> Thank you.
> 
> David Rodrigues
> ___
> 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-0062: Referencing Objective-C key-paths

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0062 “Referencing Objective-C key-paths" begins now and runs 
through April 12, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.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/0062-objc-keypaths.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

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[Guillaume Lessard via swift-evolution]

I agree. The related types (currently FlattenCollection, FlattenSequence) 
should get renamed as well.

Cheers,
Guillaume Lessard

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

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

[Max Howell via swift-evolution]

>>> I don't see that information in the man page (also, I am not familiar 
>>> enough with pkg-config to know how results described in that man page 
>>> translate to other systems).
>>> 
>>> Specifically, that man page does not seem to document where on disk the .pc 
>>> files live. How are we going to know that?
>>> 
>>> For example, one on random VM I have lying about I see .pc files here:
>>> --
>>> /# find / -name \*.pc | xargs dirname | sort | uniq
>>> /usr/lib/pkgconfig
>>> /usr/lib/x86_64-linux-gnu/pkgconfig
>>> /usr/lib/x86_64-linux-gnu/pkgconfig/mit-krb5
>>> /usr/share/pkgconfig
>>> --
>>> and the pkg-config tool appears to be able to find results from all of 
>>> those. How would we know those directory names if we don't have a 
>>> dependency on the actual tool?
>> 
>> There is a config file and an environment variable.
>> 
>> Do you need me to document them completely so that we can move forward with 
>> this?
> 
> No, not at all, I think the proposal makes complete sense and should be moved 
> along.
> 
> Nevertheless, I still want to understand how it will work... I might be 
> missing some information from the man page but I just don't see where this is 
> described. It *looks* to me like the default search list is hard coded into 
> the tool.

Best docs I have found are: 
https://people.freedesktop.org/~dbn/pkg-config-guide.html

Essentially:

The std path is /usr/lib/pkg-config and /usr/share/pkg-config, this can be 
supplemented by an env var PKG_CONFIG_PATH

It is common for system packagers to add more paths. Eg. brew does this, I 
coded it myself.

This is fine, because the additional paths can only be queried by a custom 
configured pkg-config, and in such cases we can just ask the custom configured 
pkg-config, if it’s there, there may be more paths, if it’s not then there 
cannot.

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

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Guillaume Lessard via swift-evolution]

A different direction would be to add a non-autoclosure variant to ?? that 
explicitly takes a closure.

public func ??(optional: T?, defaultValue: () throws -> T) rethrows -> T {
  switch optional {
  case .Some(let wrapped): return wrapped
  case .None: return try defaultValue()
  }
}

Then, the following works:

var v = Optional(7)
// v = nil
do {
  let i = try v ?? { throw NSError(domain: "", code: 0, userInfo: [:]) }
  print(i)
}
catch {
  print(error)
}


Or, even more generally, allow functions and operators that take autoclosure 
parameters to be used with explicit closures? I shrugged my shoulders and wrote 
an overload when I hit that limitation, but I wonder whether it is necessary.

Cheers,
Guillaume Lessard

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

[swift-evolution] Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib

[David Rönnqvist via swift-evolution]

> > On Jan 10, 2016, at 10:20 PM, Kevin Ballard via 
> > swift-evolutionwrote:
> > 
> > When the proposal is "we have a bunch of functions that match functions 
> > used in other languages, lets add a few more from the same category of 
> > functions that we missed", does there really need to be much explanation 
> > beyond "they're useful in the other languages that have them, they'd be 
> > useful for the same reasons in Swift”?
> I agree with what you’re saying, but the flip-side is: how do we scope what 
> we accept into the standard library? Just existing in some other language 
> doesn’t mean that we should (automatically) accept new standard library 
> functionality.
> 
> I’m not arguing for or against your proposal, just trying to say that this 
> rationale isn’t enough to justify adding things to the Swift standard library.
> 
> -Chris
> 

I agree with both of you: that these are useful additions, but also that it’s 
important to know where to draw the line.

Sorry if this is not the place for this discussion (my first post in this 
mailing list):
I feel that one way of moving this discussion forward is by looking more 
generally at what justifies adding new functionality that is similar to 
existing functionality.

One part of that discussion is how the new additions would serve the broader 
goals of the language.

 - Is this a style that the standard library wants to encourage?
 - Why (to serve what goal) was the existing functionality added in the first 
place?
 - Does this addition continue to serve some of the goals of that addition? 
For this proposal it would be useful to know a little bit more about the 
original discussion about woking with sequences in a functional manner and 
adding `map`, `filter`, `reduce` etc. to the standard library in the first 
place, since the proposed additions also relate to woking with sequences in a 
functional manner
For this proposal it might also be helpful knowing some of the reasoning behind 
adding `prefix`, `suffix`, `dropFirst`, and `dropLast`, since the proposed 
additions have similar functionality.

Another part of that discussion is how the new functionality relates to the 
existing. 

If the new is more is more general than the existing, then what other useful 
additions could be implemented with this new? It might be interesting to 
reverse the question and ask if the existing would be added if the new proposed 
function already existed.

If the new is a specialization of something existing, then is it something that 
many developers will end up implementing themselves? I would see this as a good 
reason to implement it in the standard library. Even more so if there is a high 
risk that individual implementations will have subtle differences in behavior 
or a high risk of bugs in the individual implementations. 

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Brandon Knope via swift-evolution]

Because I am a mailing list noob, my email wasn't CC'd to all. So here we go 
again:

Big +1 from me. 

I expected not to like this syntax but I believe it makes it far clearer. It 
always felt backwards to me to have to come up with all the constraints before 
the function signature. Maybe this is moot because you should already know what 
the function should look like before writing. But we are all human and things 
may change as we are writing it, resulting in a constant going back and forth 
from the signature to the constraints. 

It reads much more naturally (and I think it's easier to write) when the where 
clause is after the signature because you have to look *back* to the parameters 
in the function instead of looking forward. And when having to look forward, 
you have to parse a possibly long list of constraints before even finding the 
signature. Repeat this possibly for each constraint and there is some mental 
overload there. 

With the where at the end, you've already read the function signature and the 
signature is in a known easy to find place when looking back at it. 

So in summary:
- it reads more naturally
- more comfortable on the eyes
- easier to find the function signature when looking back after reading the 
constraints 

This all leads to less mental overload IMO

Brandon 

> On Apr 6, 2016, at 2:37 PM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> 
> 
> On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution 
>  wrote:
>>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>>>  wrote:
>> 
>>> 
>>> If you've ever gotten to the point where you have a sufficiently generic 
>>> interface to a thing and you need to constrain it, possibly in an 
>>> extension, maybe for a generic free function or operator, you know what a 
>>> pain the syntax can be for these kinds of operations.
>> 
>> +1 already!
>> 
>>> Or, if you're feeling ambitious, even
>>> 
>>> func anyCommonElements 
>>> where T : SequenceType, U : SequenceType,
>>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>>> (lhs: T, _ rhs: U) -> Bool
>> 
>> 
>> I would actually move them as far as after everything else, and right before 
>> the definition body. For the above function that would mean:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
>> That would make the definition look closer to what the call site looks like.
>> 
>> The same would work for generic types  too:
>> 
>> public struct Dictionary
>> where Key : Hashable
>> {
>>...
>> }
> 
> I very much like this suggestion. 
> ___
> 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] Adding a Self type name shortcut for static member access

[Joe Groff via swift-evolution]

> On Apr 6, 2016, at 11:09 PM, David Hart  wrote:
> 
> There's something I find very confusing with this proposal, and it's how Self 
> is already used in protocol definitions to represent the STATIC type of the 
> type that conforms to the protocol. I think people will be potentially very 
> confused by how Self represents different types in different contexts:
> 
> protocol Copyable {
> func copy() -> Self
> }
> 
> class Animal : Copyable {
> init() {}
> func copy() -> Animal {
> return Self.init()
> }
> }
> 
> class Cat : Animal {}
> 
> In the previous sample, wouldn't it be confusing to people if Self in the 
> protocol means Animal in the Animal type, but Self in the Animal type may 
> mean Cat?

Protocol conformances are inherited, so that's not a valid conformance, and 
protocol Self is synonymous with class Self when a class conforms. 
Animal.copy() would have to return Self to conform to Copyable.

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

Re: [swift-evolution] divisible-by operator

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 10:13 AM, Milos Rankovic via swift-evolution 
>  wrote:
> 
> Checking for divisibility is very common:
> 
> 21 % 3 == 0 // true
> 
> In fact, this is such a common use of the `%` operator that the `== 0` side 
> of the expression seems distracting in this use case. For quite a while now, 
> I’ve been using a custom operator for this, which is steadily growing on me:
> 
> 21 %== 3 // true
> 
> … which also allows me to overload it for sequences:
> 
> 21 %== [7, 3] // true
> 
> (If I’m inadvertently misusing this mailing list to share such a minor idea, 
> please tell me off so that I can learn not to do it again!)
> 

While modulo checks are common, I don't think that your proposed solution (%==) 
enhances readability or saves typing *to such extent* that it vastly improves 
over the existing art:

21 % 3 == 0 reads easily from left to right, is quick to type, is understood 
across many languages.

21 %== 3saves a few spaces, is less immediately understandable (due to the 
visual overlap with `+=` and `-=`) and would be (as far as I'm aware of) unique 
to Swift.

I applaud the thinking and creativity but I would not support the proposal.

-- E

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

> On Apr 7, 2016, at 6:17 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> Having said all this, now that we have `#Self`, I'm wondering if we still 
> want `Self` in value types. The two are *exactly* equivalent in value types 
> as far as I can tell, and `Self` in classes implies dynamic behavior which is 
> not supported by value types. The use of `Self` in class member bodies is a 
> clean win, the existence of `#Self` is a clean win, but I'm not sure we need 
> the value type thing too.

I prefer the consistency that it be available across types without exception 
more than I care that the functionality is duplicated. Plus if Swift eventually 
introduces derived value types, it may play a bigger role.

http://thread.gmane.org/gmane.comp.lang.swift.evolution/12644/ 

http://thread.gmane.org/gmane.comp.lang.swift.evolution/10652 

http://thread.gmane.org/gmane.comp.lang.swift.evolution/153 


-- E

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

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Yuta Koshizawa via swift-evolution]

Of course we can implement a library with `throws` by changing those
properties to methods. However we can think about similar cases.

```
do {
let foo: Foo = try foo(
a: Int(aString) ??? Error(),
b: Int(bString) ??? Error(),
c: Int(cString) ??? Error()
)
} catch _ {
// Error handling
}
```

`Dictionary` also returns optionals. We have already had various
functions/methods which returns optionals.

-- Yuta


2016-04-07 21:34 GMT+09:00 Thorsten Seitz via swift-evolution
:
> Why not have throwing variants of the `string` and `int` methods (in
> addition to those returning an optional)?
>
> Then you could simply write:
>
> ```
> // Decodes a JSON with SwiftyJSON
> do {
>let person: Person = try Person(
>   firstName: json["firstName"].string,
>   lastName: json["lastName"].string,
>   age: json["age"].int)
> } catch _ {
> // Error handling
> }
> ```
>
> -Thorsten
>
>
> Am 07. April 2016 um 14:01 schrieb Yuta Koshizawa via swift-evolution
> :
>
> I'd like to see some real-world examples of this before we did anything with
> it.
>
>
> The following is my real-world example.
>
> ```
> // Decodes a JSON with SwiftyJSON
> do {
> let person: Person = try Person(
> firstName: json["firstName"].string ??? Error(),
> lastName: json["lastName"].string ??? Error(),
> age: json["age"].int ??? Error()
> )
> } catch _ {
> // Error handling
> }
> ```
>
> With `guard`, we have to repeat the parameter names meaninglessly.
>
> ```
> do {
> guard let firstName = json["firstName"].string else { throw Error() }
> guard let lastName = json["lastName"].string else { throw Error() }
> guard let age = json["age"].string else { throw Error() }
> let person: Person = Person(firstName: firstName, lastName:
> lastName, age: age)
> } catch _ {
> // Error handling
> }
> ```
>
> `guard` is a statement. `???` makes an expression. Expressions are
> useful when we want to pass their return values as arguments directly.
> I think `???` is valuable to get an unwrapped value or throw an error
> as an expression.
>
> -- Yuta
>
> 2016-04-07 2:45 GMT+09:00 Jordan Rose via swift-evolution
> :
>
> I think I'm with Sean on this one. Optionals and throwing don't have enough
>
> to do with each other to actually come up with a specific operator or method
>
> for this. I can't help but see this as two ideas glued together:
>
>
> - "By this point in my execution I need a non-optional value, otherwise
>
> __"
>
> - "_ happened, therefore execution has failed and I should throw an
>
> error"
>
>
> …and I'm not sure these ideas coincide enough to be worth gluing together.
>
> There are a lot of other ways to get a non-optional value out of an optional
>
> ('??', '!', and 'guard let' with some other action), and there are a lot of
>
> other ways to fail besides an optional being nil (status code came back as
>
> error, unexpected data, connection timeout).
>
>
> I'd like to see some real-world examples of this before we did anything with
>
> it.
>
>
> Jordan
>
>
>
> On Apr 6, 2016, at 8:00, Sean Heber via swift-evolution
>
>  wrote:
>
>
> Interesting, but I’m unsure if all of it is significantly better than just
>
> using the guard that is effectively inside of the operator/func that is
>
> being proposed:
>
>
> guard let value = Int("NotANumber") else { throw
>
> InitializerError.invalidString }
>
>
> It is only a couple of characters longer and already works (it’s what I use
>
> currently). If guard allowed for a special single-expression variation so
>
> that you didn’t need to specify the ugly braces or something, it’d look
>
> prettier and be nice for a lot of other situations, too:
>
>
> guard let value = Int("NotANumber") else: throw
>
> InitializerError.invalidString
>
> guard someVal < 10 else: return false
>
> guard mustBeTrue() else: return
>
> // etc
>
>
> Not to derail this, but I sort of want this ability anywhere as a shorthand
>
> for a single-expression block.
>
>
> if something < 42: doThing()
>
> for a in list: print(a)
>
>
> But I imagine that’ll never fly. :P
>
>
> l8r
>
> Sean
>
>
>
>
> On Apr 6, 2016, at 9:46 AM, Erica Sadun via swift-evolution
>
>  wrote:
>
>
> Pyry Jahkola and I have been plugging away on the following which is
>
> preliminary enough not to qualify as an actual draft. He prefers the Mike
>
> Ash approach. I prefer the operator approach. So we have not actually
>
> settled on which one we would actually propose despite how I've written this
>
> up.
>
>
> I'm putting this out there to try to gain a consensus on:
>
>
> * Would this be a viable proposal?
>
> * If so, which of the options would work best within Swift's design and
>
> philosophy
>
>
> Thanks for your feedback.
>
>
> -- Erica
>
> Introduction
>
>
> Swift's try? keyword transforms error-throwing operations into optional
>
> values. We propose adding an 

[swift-evolution] [SR-933] Rename flatten to flattened

[Arsen Gasparyan via swift-evolution]

Hey guys,

The 'flatten()' method didn't get the Swift 3 API renaming treatment it
should have, to go along with reversed, sorted, joined, etc.
As I see Dmitri Gribenko already agree with it but we still have to discuss
it here. So what do you think?

Implementation: https://github.com/apple/swift/pull/2038

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Thorsten Seitz via swift-evolution]

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Brent Royal-Gordon via swift-evolution]

> As I understand it, the proposal is that `Self` can be used as an alias to 
> `self.dynamicType`, which is an object in the sense of entity in Swift but 
> not an instance of a class or struct. 

You don't understand it correctly.

Currently, `Self` in a class definition means "whatever subclass this object 
happens to be". So if you say this:

class Parent {
func foo() -> Self
}
class Child: Parent {}

Then on `Child`, the `foo()` function returns `Self`.

`Self` isn't supported in value types because, since you can't subclass value 
types, it always means exactly the same thing as writing the type's name. 
`Self` also isn't supported in the bodies of class members because, when you 
call members on it, it's equivalent to `self.dynamicType`. This is actually 
really strange, though, because it means that you can't actually write certain 
types explicitly. For instance:

class Foo { 
func foo() -> Self { 
let new = self.dynamicType.init()
// `new` is of type Self, but you can't actually write `let 
new: Self`
return new 
} 
required init() {} 
} 

What this proposal is saying is:

* `Self` will be allowed in value types. It will always mean the same thing as 
writing the type's name explicitly, but that's okay; it's more readable.
* `Self` will be allowed in member bodies. This will allow you to write that 
`new` line as:

let new: Self = Self()

Oh, and `#Self` will also be permitted, which is always literally just a 
shorthand for whatever type you happen to be in right now.

> My point, though is not the exact semantics of what you call the thing that 
> `Self` is but that having it and `self` in the same code will lead to 
> readability issues because you can have `self` and `Self` in the same code 
> referring to completely different things and they only differ in the case of 
> the first letter.

People seem to be okay with things like `var string: String`; having `self` be 
of type `Self` is no different.

* * *

Having said all this, now that we have `#Self`, I'm wondering if we still want 
`Self` in value types. The two are *exactly* equivalent in value types as far 
as I can tell, and `Self` in classes implies dynamic behavior which is not 
supported by value types. The use of `Self` in class member bodies is a clean 
win, the existence of `#Self` is a clean win, but I'm not sure we need the 
value type thing too.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Brent Royal-Gordon via swift-evolution]

>>  calendar.using(.Day).stride(from: startDate, to: endDate, by: 1)
> 
>> The `start` and `end` parameters could be grouped together into a
>> single parameter to match `stride(over:by:)`, but you can't put the
>> calendar or the unit into the stride—without them, there is no
>> coherent way to calculate the distance between two dates.
>> 
>> So if some types need a strider, and will need to have the method
>> structured as `strider.stride(something:by:)`, it seems like the free
>> function version for types which *don't* need a strider ought to be
>> `stride(something:by:)`. The `something.striding(by:)` design can't be
>> easily adapted to this situation.
> 
>  calendar[startDate.. 
> ?

Actually, it would need to be something like `calendar[startDate.. Stride
func advancedBy(n: Stride) -> Self
}

The problem is that there's no good way to get the calendar and unit into these 
methods. If you package them inside `Stride`, then `distanceTo` has no idea 
what calendar or unit it's supposed to return. If you package them inside 
`Self`, then `distanceTo` has two calendars and two units, and they might not 
agree (and the type system can't catch this issue). 

To fix this, you need to have a single instance which performs the calculation. 
For simple Strideable types, this instance would not do very much, but for 
dates, it would factor in the calendar and unit.

For example, suppose you modify `Strideable` so that, instead of applying to 
the values participating in the striding, it applies to the instance containing 
those values:

public protocol Strideable {
associatedtype Element: Comparable
associatedtype Stride: SignedNumber

var start: Value
var end: Value

public func distance(from earlier: Element, to later: Element) 
-> Stride
public func advance(element: Element, by stride: Stride) -> 
Element
}

Now, with some *really* aggressive conditional conformance work, you could do 
this:

extension Range: Strideable where Element == Int {
typealias Stride = Int

public func distance(from earlier: Int, to later: Int) -> Int {
return later - earlier
}
public func advance(element: Int, by stride: Int) {
return value + stride
}
}
extension Range: Strideable where Element == Double {
// Ignoring the accumulation issue.
typealias Stride = Double

public func distance(from earlier: Int, to later: Int) -> Int {
return later - earlier
}
public func advance(element: Double, by stride: Double) {
return element + stride
}
}
// etc., for each type you care about.
// 
// This could be automated by creating a `RangeStrideable` protocol 
similar to the old Strideable,
// and having types with this automatic behavior conform to it. You 
could then have a single:
//  extension Range: Strideable where Element: RangeStrideable

It would not be possible to stride directly over a range of NSDates, but you 
could have a "calendar range" which could be `Strideable`, like so:

struct NSCalendarRange {
var start: NSDate
var end: NSDate

var calendar: NSCalendar
var unit: NSCalendarUnit

var options: NSCalendarOptions
// This mainly contains rounding options. Interestingly, NSDate 
is like Double in that 
// it accumulates errors through repeated addition. To fix 
that, I have discovered 
// a truly marvelous design which this email is too small to 
contain.
}
extension NSCalendarRange: Strideable {
typealias Value = NSDate
typealias Stride = Int

public func distance(from earlier: NSDate, to later: NSDate) -> 
Int {
let components = calendar.components(unit, from: 
earlier, to: later, options: options)
return components.value(forComponent: unit)
}
public func advance(value: NSDate, by stride: Int) -> NSDate {
return 

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Yuta Koshizawa via swift-evolution]

> I'd like to see some real-world examples of this before we did anything with 
> it.

The following is my real-world example.

```
// Decodes a JSON with SwiftyJSON
do {
  let person: Person = try Person(
firstName: json["firstName"].string ??? Error(),
lastName: json["lastName"].string ??? Error(),
age: json["age"].int ??? Error()
  )
} catch _ {
  // Error handling
}
```

With `guard`, we have to repeat the parameter names meaninglessly.

```
do {
guard let firstName = json["firstName"].string else { throw Error() }
guard let lastName = json["lastName"].string else { throw Error() }
guard let age = json["age"].string else { throw Error() }
let person: Person = Person(firstName: firstName, lastName:
lastName, age: age)
} catch _ {
  // Error handling
}
```

`guard` is a statement. `???` makes an expression. Expressions are
useful when we want to pass their return values as arguments directly.
I think `???` is valuable to get an unwrapped value or throw an error
as an expression.

-- Yuta

2016-04-07 2:45 GMT+09:00 Jordan Rose via swift-evolution
:
> I think I'm with Sean on this one. Optionals and throwing don't have enough
> to do with each other to actually come up with a specific operator or method
> for this. I can't help but see this as two ideas glued together:
>
> - "By this point in my execution I need a non-optional value, otherwise
> __"
> - "_ happened, therefore execution has failed and I should throw an
> error"
>
> …and I'm not sure these ideas coincide enough to be worth gluing together.
> There are a lot of other ways to get a non-optional value out of an optional
> ('??', '!', and 'guard let' with some other action), and there are a lot of
> other ways to fail besides an optional being nil (status code came back as
> error, unexpected data, connection timeout).
>
> I'd like to see some real-world examples of this before we did anything with
> it.
>
> Jordan
>
>
> On Apr 6, 2016, at 8:00, Sean Heber via swift-evolution
>  wrote:
>
> Interesting, but I’m unsure if all of it is significantly better than just
> using the guard that is effectively inside of the operator/func that is
> being proposed:
>
> guard let value = Int("NotANumber") else { throw
> InitializerError.invalidString }
>
> It is only a couple of characters longer and already works (it’s what I use
> currently). If guard allowed for a special single-expression variation so
> that you didn’t need to specify the ugly braces or something, it’d look
> prettier and be nice for a lot of other situations, too:
>
> guard let value = Int("NotANumber") else: throw
> InitializerError.invalidString
> guard someVal < 10 else: return false
> guard mustBeTrue() else: return
> // etc
>
> Not to derail this, but I sort of want this ability anywhere as a shorthand
> for a single-expression block.
>
> if something < 42: doThing()
> for a in list: print(a)
>
> But I imagine that’ll never fly. :P
>
> l8r
> Sean
>
>
>
> On Apr 6, 2016, at 9:46 AM, Erica Sadun via swift-evolution
>  wrote:
>
> Pyry Jahkola and I have been plugging away on the following which is
> preliminary enough not to qualify as an actual draft. He prefers the Mike
> Ash approach. I prefer the operator approach. So we have not actually
> settled on which one we would actually propose despite how I've written this
> up.
>
> I'm putting this out there to try to gain a consensus on:
>
> * Would this be a viable proposal?
> * If so, which of the options would work best within Swift's design and
> philosophy
>
> Thanks for your feedback.
>
> -- Erica
> Introduction
>
> Swift's try? keyword transforms error-throwing operations into optional
> values. We propose adding an error-throwing nil-coalescing operator to the
> Swift standard library. This operator will coerce optional results into
> Swift's error-handling system.
>
> This proposal was discussed on the Swift Evolution list in the name thread.
>
> Motivation
>
> Any decision to expand Swift's set of standard operators should be taken
> thoughtfully and judiciously. Moving unaudited or deliberately
> non-error-handling nil-returning methods and failable initializers into
> Swift's error system should be a common enough use case to justify
> introducing a new operator.
>
> Detail Design
>
> We propose adding a new operator that works along the following lines:
>
> infix operator ??? {}
>
> func ???(lhs: T?, @autoclosure error: () -> ErrorType) throws -> T {
>guard case let value? = lhs else { throw error() }
>return value
> }
>
> The use-case would look like this:
>
> do {
>let error = Error(reason: "Invalid string passed to Integer initializer")
>let value = try Int("NotANumber") ??? InitializerError.invalidString
>print("Value", value)
> } catch { print(error) }
>
> Note
>
> SE-0047 (warn unused result by default) and SE-0049 (move autoclosure) both
> affect many of the snippets in this 

[swift-evolution] [Proposal] Invert the order of pattern match operator

[David Rodrigues via swift-evolution]

Hi all,

Swift has a pattern match operator, ~=, which is unknown to many (like me
until a few weeks ago), that performs a match between a value and a certain
pattern, e.g. checking if an integer value is contained in a range of
integers.

This operator may be little known, but it plays a key role in the language
since it's used behind the scenes to support expression patterns in
`switch` statement case labels, which we all know are extremely popular.

let point = (2, 4)
switch point {
case (0, 0):
print("The point is at the origin")
case (0...4, 0...4):
print("The point is in the subregion")
default:
break
}

Most of the time we don't use the operator directly but it is available and
can be handy in certain conditions.

let point = (2, 4)
switch point {
case (let x, let y) where 0...4 ~= x && 0...4 ~= y:
print("The point is in the subregion")
default:
break
}

However the current syntax is not ideal (in my opinion). We're not really
declaring the operation that we want to do, and that has an impact in the
expressivity and readability of the code. Currently we're doing matches
like "if blue is the ocean" instead of "if the ocean is blue" or "if the
ocean contains the whale" instead of "if the whale is in the ocean".

For that reason, I would like to suggest inverting the order of the
operator to match more closely our logical thought.

case (let x, let y) where x =~ 0...4 && y =~ 0...4: // Proposed
// vs
case (let x, let y) where 0...4 ~= x && 0...4 ~= y: // Current

I have an ongoing proposal to suggest this change and it contains a little
more context. It is available here:

https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/-invert-order-of-pattern-match-operator.md
.

Any feedback is very welcome.

Thank you.

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Haravikk via swift-evolution]

I quite like this variation, so I’m a +1 for that.

However, I think this would be greatly helped if we could define protocol 
generics more like type generics like so:

protocol Foo { … }
func anyStringFoo(lhs:Foo) { … }

But yeah, for the more complicated cases, it makes a lot of sense to relocate 
the where clause away from the main signature. I’d maybe still allow 
declarations of type though like-so:

func anyCommonElements(lhs:T, _ rhs:U) 
-> Bool
where T.Generator.Element:Equatable, T.Generator.Element == 
U.Generator.Element

Perhaps allowing us the choice of doing it this way at least.

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>  wrote:
> 
>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>> > wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.
> 
> +1 already!
> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
> 
> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
> 
> — Pyry
> ___
> 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] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Haravikk via swift-evolution]

> On 7 Apr 2016, at 08:20, Vladimir.S via swift-evolution 
>  wrote:
> 
> (TLDR: Suggest to change successor() method for Int values to follow default 
> Swift rules for integer overflow. Probably some kind of successorWithOverflow 
> could be introduced to use when needed)

I’m a +1 for this; in fact, this is just how I assumed they worked, as the 
postcondition requirement for .successor() is that n.successor() > n if I 
remember right, which clearly can’t be the case if the limit of the integer is 
reached, so a runtime error seems reasonable.

> (Btw, I personally totally disagree with the chosen solution regarding 
> removing ++/--, I believe that we should leave ++ and -- as form of i += 1 
> code. I.e. only as assignment for variable, drop all other variants of using 
> ++ and --.
> And i += 1 is not just 1 char longer than i++ : in first case you have to 
> press 4 different keys/combinations and just one(the same twice) in second 
> case.
> Just personal opinion :-) )

These were removed for a bunch of reasons:
Requiring the use of += 1 or -=1 is more consistent (assignment always includes 
an equals sign)
It can easily lead to confusing cases when used in function parameters or 
complex statements, making it unclear at a glance what a value will actually 
be. Some people argued that the operator should just have no return type to 
counter this.
If the operator had no return type to address #2 then it basically becomes 
redundant when i += 1 is identical, but also more flexible.
They were most commonly used within C-style for loops, which Swift no longer 
has.
So I’m a -1 to anyone wanting those back ;)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Vladimir.S via swift-evolution]

Hi All!
(Please let me know if that was already discussed. Searched, found nothing 
related to such proposal.)


(TLDR: Suggest to change successor() method for Int values to follow 
default Swift rules for integer overflow. Probably some kind of 
successorWithOverflow could be introduced to use when needed)


Swift protects(trying to protect) us from Integer overflow problem, i.e. 
when we want to do this:

let i : Int8 = Int8.max
let k : Int8 = i + 1
, we will have run-time error on second line. Swift protects us from using 
(most likely) unexpected negative value (-128) for  variable in this case.


I believe this is really great and prevents our code from undefined 
behavior and some security problems.
When we adds something to our Int variable in most cases we presume(and 
create next code with that presumption) that in result we have a bigger 
value in our variable. Not smaller and not negative(in case of signed Int).


If we really needs Integer overflow in our code(for example for some math), 
we use special operator explicitly:

let k = i &+ 1
and in this case we'll have -128 in  with no errors.

But. .successor() .predecessor() methods for Int values do not follow these 
rules for overflow situations. I.e. :

let i : Int8 = Int8.max
let k : Int8 = i.successor()
- is OK for current Swift compiler. We have i==127 and k==-128, no run-time 
error.


I'm totally confused in this case. No explicit 'marker' to allow integer 
overflow. I don't expect to have (-128) in k, I'm calling successor() to 
get next mathematical value for  and (-128) is not next value for (127).


Even worse. In Swift 3.0 we have no ++ operator. You can find that often 
.successor/.predecessor are recommended as replacement for ++ operator.
I.e. i++  =>  i.successor(), I believe that many will choose this form over 
i += 1 or i + 1. And in this case we lose our integer overflow protection 
from Swift.


Suggestion is: change .successor/.predecessor for Int values to follow 
overflow rules and probable introduce some 
.successorWithOverflow/.predecessorWithOverflow if one need them in code.


Please let me know what do you think about this suggestion. Thank you.

P.S. Sorry for my English.

(Btw, I personally totally disagree with the chosen solution regarding 
removing ++/--, I believe that we should leave ++ and -- as form of i += 1 
code. I.e. only as assignment for variable, drop all other variants of 
using ++ and --.
And i += 1 is not just 1 char longer than i++ : in first case you have to 
press 4 different keys/combinations and just one(the same twice) in second 
case.

Just personal opinion :-) )

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Thorsten Seitz via swift-evolution]

Dijkstra is talking about intervals of natural numbers, i.e. indices.
Range is much more general than that, including floating point ranges, so 
Dijkstra's arguments do not apply here.

-Thorsten 

Am 06.04.2016 um 23:41 schrieb Brent Royal-Gordon via swift-evolution 
:

>> From a purely numerically aesthetic point of view, I'd much prefer ranges to 
>> be 
>> openable and closable at both ends. 
>> 
>> My primary use-case has been teaching math using playgrounds but I'm sure 
>> there are lots of other real-world situations more specific to common 
>> numerical
>> method tasks.
> 
> By coincidence, a Perl hacker I know commented on Twitter yesterday that he 
> thought 1-based arrays were the way to go in the 21st century. Somebody 
> replying to that suggestion linked to a note by Dijkstra that's relevant to 
> this conversation: 
> 
> 
> I'd suggest everyone in this discussion should read it—it's only about 700 
> words—but to summarize:
> 
>1. The semantic Swift refers to as `..<` is the most natural range 
> convention.
>2. Relatedly, zero-based indexing is the most natural indexing convention.
> 
> If we agree with Dijkstra's logic, then the only reason to support `>..` is 
> for ranges where start > end—that is, when we're constructing a reversed 
> range. But if we decide to support striding backwards by using a forward 
> range and a negative stride, then that covers the reverse use case. Thus, we 
> would need neither additional range operators, nor reversed ranges.
> 
> As for the `range.striding(by:)` vs `stride(over:by:)` question, my concerns 
> there are, to be honest, mainly aesthetic. The need for parentheses around 
> the range operator is more or less unavoidable, but I think they make the 
> construct very ugly. However, I also think that the `stride(over:by:)` syntax 
> (or, for that matter `stride(from:to:by:)`) look more constructor-y (they are 
> only *not* constructors now because of the overloading), and I think it opens 
> us up to parallel constructs like the `induce(from:while:by:)` function I've 
> been working on.
> 
> -- 
> 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

Re: [swift-evolution] Feature proposal: Range operator with step

[Thorsten Seitz via swift-evolution]

> Am 06.04.2016 um 23:26 schrieb Stephen Canon via swift-evolution 
> :
> 
> 
>> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>>> on Wed Apr 06 2016, Erica Sadun  wrote:
>>> 
>>>   On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution
>>>    wrote:
>>> 
>>>   on Wed Apr 06 2016, Xiaodi Wu  wrote:
>>> 
>>>   On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>>>    wrote:
>>> 
>>>   You if you need to represent `<..` intervals in scientific computing,
>>>   that's a pretty compelling argument for supporting them.
>>> 
>>>   I'd like to be able to represent any of those as
>>>   Intervals-which-are-now-Ranges. It makes sense to do so 
>>> because
>>>   the
>>>   things I want to do with them, such as clamping and testing if
>>>   some
>>>   value is contained, are exactly what Intervals-now-Ranges
>>>   provide.
>>>   Looking around, it seems many other languages provide only 
>>> what
>>>   Swift
>>>   currently does, but Perl does provide `..`, `..^`, `^..`, and
>>>   `^..^`
>>>   (which, brought over to Swift, would be `...`, `..<`, `<..`, 
>>> and
>>>   `<.<`).
>>> 
>>>   Do we need fully-open ranges too?
>>> 
>>>   I haven't encountered a need for open ranges, but I would expect that
>>>   other applications in scientific computing could make use of them.
>>>   I rather like Pyry's suggestions below. 
>>> 
>>>   Below?
>>> 
>>> Logically in time below.
>> 
>> Oh! In my application, time flows downward.
>> 
>>> 
>>> I believe the following is a valid conversion of the Xiaodi Wu below into 
>>> the
>>> Dave A domain.
>>> 
>>>   On Apr 6, 2016, at 2:29 PM, Pyry Jahkola via swift-evolution
>>>    wrote:
>>> 
>>>   I think a sensible specification would be that with a positive step size,
>>>   the count starts from the lower bound, and with a negative one, it starts
>>>   from the upper bound (inclusive or exclusive). Thus, the following 
>>> examples
>>>   should cover all the corner cases:
>>> 
>>>   (0 ... 9).striding(by: 2) == [0, 2, 4, 6, 8]
>>>   (0 ..< 9).striding(by: 2) == [0, 2, 4, 6, 8]
>>>   (0 <.. 9).striding(by: 2) == [2, 4, 6, 8]
>>>   (0 <.< 9).striding(by: 2) == [2, 4, 6, 8]
>>> 
>>>   (0 ... 9).striding(by: 3) == [0, 3, 6, 9]
>>>   (0 ..< 9).striding(by: 3) == [0, 3, 6]
>>>   (0 <.. 9).striding(by: 3) == [3, 6, 9]
>>>   (0 <.< 9).striding(by: 3) == [3, 6]
>>> 
>>>   (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1]
>>>   (0 ..< 9).striding(by: -2) == [7, 5, 3, 1]
>>>   (0 <.. 9).striding(by: -2) == [9, 7, 5, 3, 1]
>>>   (0 <.< 9).striding(by: -2) == [7, 5, 3, 1]
>>> 
>>>   (0 ... 9).striding(by: -3) == [9, 6, 3, 0]
>>>   (0 ..< 9).striding(by: -3) == [6, 3, 0]
>>>   (0 <.. 9).striding(by: -3) == [9, 6, 3]
>>>   (0 <.< 9).striding(by: -3) == [6, 3]
>> 
>> These all look reasonable to me.
> 
> Agreed.

I agree as well. Makes sense.

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Thorsten Seitz via swift-evolution]

> Am 06.04.2016 um 23:03 schrieb Dave Abrahams via swift-evolution 
> :
> 
> 
>> on Wed Apr 06 2016, Erica Sadun  wrote:
>> 
>>On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>Guidance:
>> 
>>When using odd integer literals to produce an even number sequence,
>>prefer the `...` operator to the `..<` operator and change your ending
>>literal to an even number.
>> 
>>I don't think you can fix counterintuitive behavior with guidance. 
>> 
>>(1..<199).striding(by: -2) is the first way I'd reach for to express
>>197, 195, ..., 3, 1
>> 
>> Yes, but you can with warnings and fixits. 
>> 
>> * The compiler should issue a warning for any use of 
>> 
>> (n..> 
>> with a fixit of "replace (n..> whether n or m is known at compile time 
>> 
>> * If v cannot be known at compile time, I think the compiler should
>> always prefer ... to ..<.
>> 
>> * The compiler should not allow
>> 
>> (n..> 
>> where v is known at compile time to be a negative constant. There should 
>> also be a runtime precondition that raises a fatal error should a negative 
>> v be used with a half-open interval.
> 
> You can lessen the impact of any design choice by adding warnings and
> fixits, but I'm pretty sure it's better to make a choice that doesn't
> require them.

Absolutely! Having to add warnings and fixits just demonstrates that the design 
is confusing. 

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[David Hart via swift-evolution]

There's something I find very confusing with this proposal, and it's how Self 
is already used in protocol definitions to represent the STATIC type of the 
type that conforms to the protocol. I think people will be potentially very 
confused by how Self represents different types in different contexts:

protocol Copyable {
func copy() -> Self
}

class Animal : Copyable {
init() {}
func copy() -> Animal {
return Self.init()
}
}

class Cat : Animal {}

In the previous sample, wouldn't it be confusing to people if Self in the 
protocol means Animal in the Animal type, but Self in the Animal type may mean 
Cat?

Sent from my iPad
> On 06 Apr 2016, at 18:51, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 5, 2016, at 4:04 PM, Joe Groff  wrote:
>>> 
>>> 
>>> On Apr 5, 2016, at 3:02 PM, Erica Sadun  wrote:
>>> 
>>> As the discussion seems to be quieting down, I've tried to summarize the 
>>> on-list discussion and distill it into a preliminary proposal draft. Please 
>>> let me know if this covers what you think it should or if I've entirely 
>>> missed the mark. (It wouldn't be the first time.)
>>> 
>>> Regards,  -- Erica
> 
> 
> Pull Request 248: https://github.com/apple/swift-evolution/pull/248
> 
> Within a class scope, Self means "the dynamic class of self". This proposal 
> extends that courtesy to value types, where dynamic Self will match a 
> construct's static type, and to the bodies of class members, where it may 
> not. It also introduces a static variation, #Self that expands to static type 
> of the code it appears within.
> 
> This proposal was discussed on the Swift Evolution list in the [Pitch] Adding 
> a Self type name shortcut for static member access thread.
> 
> Thanks, -- 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