Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Brent Royal-Gordon via swift-evolution]

> Swift currently does not allow operators to use $ - I assume because the 
> grammar reserves it in one place: `implicit-parameter-name`.  I don't see why 
> an entire class of identifiers has been eliminated, so I propose $ instead be 
> reclassified as an `operator-character` so it can be used mixed in with other 
> such characters, but prevents the introduction of `$Identifier`-style 
> declarations that might conflict with implicit parameters.

I believe the reason you don't see any other $ variables is that they're 
reserved for the debugger and REPL.

brent@Brents-MacBook-Pro ~/D/Code> swift
Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 
clang-700.1.81). Type :help for assistance.
  1> "foo"
$R0: String = "foo"
  2> print($R0)
foo

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Dave Abrahams via swift-evolution]

> On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote:
>>> `buffered` is no more problematic than `lazy` is. In fact, calling 
>>> `buffered` actually doesn't have any side-effects at all (it can avoid 
>>> fetching the first element until you call `first` on the result of 
>>> `buffered`).
>> 
>> If `seq` is a single-pass sequence, then `seq.buffered.first` will consume 
>> an element from `seq`, even though you only accessed two properties. That's 
>> why I call it problematic.
>> 
>> (If calling `buffered` somehow rendered the original sequence unusable—for 
>> instance, if we had some way to express that the `BufferedSequence` takes 
>> unique ownership of its base—this wouldn't bother me as much.)
> 
> If `sequence` is a single-pass sequence, wrapping it in any other sequence 
> type and then doing anything with that other sequence type makes the original 
> sequence unusable (or rather, you can still use it but the elements yielded 
> from any further access to the original sequence can be completely arbitrary).
> 
> And for the record we already have precedent for the specific case of 
> `seq.prop1.prop2` destructively consuming the original sequence: 
> `seq.lazy.array`.

Yes, and there are arguments for dropping “.array” as a property.  The 
convention is that “conversions” (ill-defined, I know) use constructor syntax, 
and we are currently heading towards the elimination of "convenience” 
interfaces that duplicate functionality, so we might end up with Array(seq).  

All that said, single-pass Sequences are just weird in that they get mutated 
without calling any mutating methods on them; you mutate them by calling a 
mutating method on a separate generator instance.  In other words, they 
fundamentally have reference semantics.  There may be some better way to 
address this whole area, but we’ll have to go much deeper than merely poking at 
the question of a  `.first` property. 

-Dave

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

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Kevin Ballard via swift-evolution]

On Sat, Jan 2, 2016, at 10:38 PM, Douglas Gregor wrote:
> * What is your evaluation of the proposal?

+1

I have a preference for `associated` instead of `associatedtype`, but
it's not a big deal.

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

Personally I don't think it's a particularly significant problem, but it
is a small one that this change would help with, and the change itself
is pretty minor (and can be automated in 100% of cases).

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

Yes.

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

Rust has the same feature, although it uses the keyword `type` instead
of `typealias`. And they still use the same keyword `type` for
associated types inside of traits. But rust uses associated types much
more sparingly than Swift does (Rust traits can have generic type
parameters, and in fact associated types were a fairly late addition to
the language). Swift is also much more of a teaching language than Rust
is, so I think this change is quite reasonable for Swift.

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

I followed the original swift-evolution thread and read the proposal
again just now.

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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Jacob Bandes-Storch via swift-evolution]

+10

On Sat, Jan 2, 2016 at 11:36 PM, Developer via swift-evolution <
swift-evolution@swift.org> wrote:

> Swift currently does not allow operators to use $ - I assume because the
> grammar reserves it in one place: `implicit-parameter-name`.  I don't see
> why an entire class of identifiers has been eliminated, so I propose $
> instead be reclassified as an `operator-character` so it can be used mixed
> in with other such characters, but prevents the introduction of
> `$Identifier`-style declarations that might conflict with implicit
> parameters.
>
> ~Robert Widmann
> ___
> 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] [Proposal]: Free the '$' Symbol!

[Developer via swift-evolution]

Swift currently does not allow operators to use $ - I assume because the 
grammar reserves it in one place: `implicit-parameter-name`.  I don't see why 
an entire class of identifiers has been eliminated, so I propose $ instead be 
reclassified as an `operator-character` so it can be used mixed in with other 
such characters, but prevents the introduction of `$Identifier`-style 
declarations that might conflict with implicit parameters.

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Kevin Ballard via swift-evolution]

On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote:
> > `buffered` is no more problematic than `lazy` is. In fact, calling 
> > `buffered` actually doesn't have any side-effects at all (it can avoid 
> > fetching the first element until you call `first` on the result of 
> > `buffered`).
> 
> If `seq` is a single-pass sequence, then `seq.buffered.first` will consume an 
> element from `seq`, even though you only accessed two properties. That's why 
> I call it problematic.
> 
> (If calling `buffered` somehow rendered the original sequence unusable—for 
> instance, if we had some way to express that the `BufferedSequence` takes 
> unique ownership of its base—this wouldn't bother me as much.)

If `sequence` is a single-pass sequence, wrapping it in any other sequence type 
and then doing anything with that other sequence type makes the original 
sequence unusable (or rather, you can still use it but the elements yielded 
from any further access to the original sequence can be completely arbitrary).

And for the record we already have precedent for the specific case of 
`seq.prop1.prop2` destructively consuming the original sequence: 
`seq.lazy.array`.

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Brent Royal-Gordon via swift-evolution]

> `buffered` is no more problematic than `lazy` is. In fact, calling `buffered` 
> actually doesn't have any side-effects at all (it can avoid fetching the 
> first element until you call `first` on the result of `buffered`).

If `seq` is a single-pass sequence, then `seq.buffered.first` will consume an 
element from `seq`, even though you only accessed two properties. That's why I 
call it problematic.

(If calling `buffered` somehow rendered the original sequence unusable—for 
instance, if we had some way to express that the `BufferedSequence` takes 
unique ownership of its base—this wouldn't bother me as much.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

I think it's a great idea. The shift in meaning when you use `typealias` in a 
protocol is enormous—not only is an associated type far more different from a 
typealias than most protocol requirements, but it also changes the way you can 
use the protocol itself—and sharing a keyword gives you no hint of that. It 
also means that you can't search the documentation for the keyword to 
understand what it means. Switching to an `associatedtype` keyword fixes these 
issues.

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

Absolutely. I have seen nothing but confusion surrounding the use of associated 
types in protocols, and anything that might clear that up is a great idea.

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

Yes. Swift typically doesn't shy away from introducing new keywords to 
accurately capture semantics, and that's what `associatedtype` does.

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

I have not used any such languages.

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

I've participated in some of the discussions of this proposal, particularly the 
discussion of alternative keywords. There I advocated `associated`, but I will 
admit that `associatedtype` is slightly clearer.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Kevin Ballard via swift-evolution]

On Sat, Jan 2, 2016, at 09:50 PM, Brent Royal-Gordon via swift-evolution wrote:
> > If I don’t sound sympathetic, it’s because nobody has shown a use-case for 
> > this functionality, and until I see one I am going to have a hard time 
> > believing there’s a problem worth solving.  If you want to make the case 
> > that we need something like this, please show me why. 
> 
> Didn't this thread start off with a use case?
> 
>   seq.lazy.filter(predicate).first// is not actually 
> lazy, and Swift provides no good way to do this
> 
> One way to fix this is to add `first` to `SequenceType`, but it feels strange 
> for a property to potentially consume part of the sequence. `buffered` 
> ultimately has the same problem. By representing this as a function, it at 
> least looks like something that might have side effects.

`buffered` is no more problematic than `lazy` is. In fact, calling `buffered` 
actually doesn't have any side-effects at all (it can avoid fetching the first 
element until you call `first` on the result of `buffered`).

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Gwendal Roué via swift-evolution]

> Le 3 janv. 2016 à 01:58, Kevin Ballard  a écrit :
> 
>>> seq.generate().next() may not be nice, but no one can get fooled by it.
>> 
>> Well, for one thing, because it doesn't work. […]
> 
> Exactly. If `seq.generate().next()` worked, I'd be perfectly happy with that. 
> […]

Right.

> Le 3 janv. 2016 à 06:50, Brent Royal-Gordon  a écrit :
> 
>> If I don’t sound sympathetic, it’s because nobody has shown a use-case for 
>> this functionality, and until I see one I am going to have a hard time 
>> believing there’s a problem worth solving.  If you want to make the case 
>> that we need something like this, please show me why. 
> 
> Didn't this thread start off with a use case?
> 
>   seq.lazy.filter(predicate).first// is not actually 
> lazy, and Swift provides no good way to do this
> 
> One way to fix this is to add `first` to `SequenceType`, but it feels strange 
> for a property to potentially consume part of the sequence. `buffered` 
> ultimately has the same problem. By representing this as a function, it at 
> least looks like something that might have side effects.

Out of honesty, here is another use case: `database.fetch(…).first`.

Since this is not possible today, database APIs have to expose another 
`fetchFirst()` (fetchOne, pluck, whatever) method, that uses a temporary 
generator on the sequence returned by the fetch() method.

If sequence.first would exist, the database API would not have to define this 
extra method.

Gwendal

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

Re: [swift-evolution] Empower String type with regular expression

[John Joyce via swift-evolution]

> > On Dec 8, 2015, at 12:14 PM, Jerome Paschoud via swift-evolution 
> >  > > wrote:
> > 
> > I would like to see the String type to support regular expression per 
> > default. I think that a language that advertise itself as being a good 
> > scripting language should provide in its default implementation an easy way 
> > (=~ for example in Perl) to use regular expressions. I know that one can 
> > use the NSRegularExpression, but who really what to first create an 
> > NSRegularExpression object(whit all the nice escaping operation that come 
> > with every \), then get a NSTextCheckingResult, then get a range (and what 
> > I mean is a NSRange and not a NSRange) and finally perform 
> > slicing of your original string. 
> 
> Just MHO, but I’d really really like to see proper regex support in Swift 
> someday.
> 
> I think it could fit naturally into the pattern matching syntax we already 
> have - the obvious syntax for this pattern would use // delimiters. 
> 
> It is also probably worth burning first-class language support for regexes.  
> This would allow specifying variable captures inline in the pattern, would 
> allow flexible syntax for defining regexes, support powerful extensions to 
> the base regex model (e.g. Perl 6 style), and would provide better 
> compile-time checking and error recovery for mistakes.
> 
> -Chris
I know this is an old thread already, but this sure would be one of the major 
breakout pieces of functionality.
If Swift had native regular expressions, without all the noise you see in the 
Objective-C API that exposes ICU regular expressions, the adoption rate would 
be huge.
If they were *truly* native, as in somebody sat down and built an NFA (or one 
of the fancier approaches that mixes with DFA) state machine, Swift's 
best-in-class Unicode support would and could result in amazing things.
It'd boost the scripting use of Swift tremendously and seal the deal as a 
server side language.

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

Re: [swift-evolution] Better syntax for deferred?

[Robert S Mozayeni via swift-evolution]

Not only that, but placing defer at the end of a scope, where any other code 
may never get executed if there’s an early return, kind of violates the whole 
concept of control flow.

func f() throws {
let o = file(path: "")
o.openFile()
do {
try o.write(self.data)
}

print("success")
always { o.close() }
}

What happens if o.write fails? Going with always would imply that we either…

A) put the `always` in every possible place the scope might exit, defeating the 
whole purpose of defer/always. Maury, I’m assuming you’re not actually 
suggesting that, which would leave: B) if the main scope of the function exits 
at any point, drop down to the `always` at the end of the scope and execute it. 
But then, what about the surrounding code at the end of the main scope? Like I 
said, I think this would violate the whole concept of control flow by 
cherry-picking a specific type of command that is always executed within a 
scope, even if that command is in some place the control flow doesn’t reach.

Unless I’m misinterpreting something (let me know if I am) this seems less 
intuitive than `defer` was to begin with.

-Robert


> On Jan 2, 2016, at 3:17 PM, Dennis Lysenko via swift-evolution 
>  wrote:
> 
> Deferring at the end of the function removes the ability to defer actions on 
> variables introduced in an inner scope.
> 
> 
> On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I have the terrible feeling something is wrong with my posts so that they get 
> caught by spamfilters or similar…
> 
> But as others stated as well:
> defer has a use case that is a little bit different from what you want to 
> archive.
> 
> > Why not use a solution that is widely used and better?
> I'm curious:
> Which languages have this "always" construct?
> ___
> 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] Asserts should not cause undefined behaviour

[Arnold via swift-evolution]

Sent from my iPhone

> On Jan 2, 2016, at 6:35 PM, Dave Abrahams  wrote:
> 
> 
>> On Jan 2, 2016, at 2:57 AM, Arnold  wrote:
>> 
>> 'assert' evaluates the condition and aborts only in Odebug builds.
>> 
>> 'precondition' evaluates the condition and aborts also in optimized -0 
>> builds.
>> 
>> As far as I remember  the decision was made to give it this semantics to 
>> mimic C's assert() function.
>> 
>> If an abort is desired in optimized builds one should use 'precondition’.
> 
> Thanks, Arnold, but this doesn’t address the key question: in -O builds, does 
> the optimizer make optimizations based on the assumption that asserts would 
> not fire if they were enabled?

I think you answered this question already in your follow up email: no the 
optimizer does not make optimization based on this assumption.


>> Sent from my iPhone
>> 
>>> On Jan 2, 2016, at 8:27 AM, Dave Abrahams  wrote:
>>> 
>>> 
> On Jan 1, 2016, at 11:25 PM, Chris Lattner  wrote:
> 
> On Dec 31, 2015, at 1:56 PM, Dave Abrahams  wrote:
>>> 2) Adding asserts to code should not make the code more dangerous 
>>> whatever the build. Assuming the truth of the assert may lead to 
>>> runtime safety checks being skipped and undefined behaviour when a 
>>> no-op would be a safe behaviour.
>> 
>> This only affects code built with -Ounchecked, which is definitely not a 
>> safe mode to build your code.  The intention of this mode is that you 
>> can use it to get a performance boost, if you believe your code to be 
>> sufficiently tested.  This mode, which isn’t the default in any way, 
>> intentionally takes the guard rails off to get better performance.
>> 
>> If you don’t like that model, don’t use this mode.
> 
> Let’s just consider -O; I think I understand Joseph’s objection here, and 
> it seems valid.
 
 Ah, good point.
 
> Normally in -O, we say that if you stay in the “safe subset” of Swift 
> code, you never get undefined behavior, even if there’s a bug in your 
> code.  You might get *unpredictable* behavior of course, but presumably 
> guaranteeing no undefined behavior rules out large classes of problems, 
> including many security holes.  Now suppose you decide to be responsible 
> and add some asserts to help you catch bugs during development.  
> Hopefully they help you catch all the bugs, but what if they don’t?  All 
> of a sudden, if you still have a bug when you ship, you now have 
> undefined behavior.  As much as I’m a fan of assertions having 
> optimization benefits, It seems a little perverse that using them could 
> make shipping code less secure.
 
 Yes, I agree.  -O should not imply undefined behavior in the case of an 
 assert() predicate being dynamically false.
 
 It sounds like we just need a documentation update here?
>>> 
>>> I’m pretty sure the documentation reflects assumptions that the optimizer 
>>> is already taking advantage of, but the performance team knows for sure.
>>> 
>>> -Dave
> 
> -Dave
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Asserts should not cause undefined behaviour

[Arnold via swift-evolution]

'assert' evaluates the condition and aborts only in Odebug builds.

'precondition' evaluates the condition and aborts also in optimized -0 builds.

As far as I remember  the decision was made to give it this semantics to mimic 
C's assert() function.

If an abort is desired in optimized builds one should use 'precondition'.

Sent from my iPhone

> On Jan 2, 2016, at 8:27 AM, Dave Abrahams  wrote:
> 
> 
>>> On Jan 1, 2016, at 11:25 PM, Chris Lattner  wrote:
>>> 
>>> On Dec 31, 2015, at 1:56 PM, Dave Abrahams  wrote:
> 2) Adding asserts to code should not make the code more dangerous 
> whatever the build. Assuming the truth of the assert may lead to runtime 
> safety checks being skipped and undefined behaviour when a no-op would be 
> a safe behaviour.
 
 This only affects code built with -Ounchecked, which is definitely not a 
 safe mode to build your code.  The intention of this mode is that you can 
 use it to get a performance boost, if you believe your code to be 
 sufficiently tested.  This mode, which isn’t the default in any way, 
 intentionally takes the guard rails off to get better performance.
 
 If you don’t like that model, don’t use this mode.
>>> 
>>> Let’s just consider -O; I think I understand Joseph’s objection here, and 
>>> it seems valid.
>> 
>> Ah, good point.
>> 
>>> Normally in -O, we say that if you stay in the “safe subset” of Swift code, 
>>> you never get undefined behavior, even if there’s a bug in your code.  You 
>>> might get *unpredictable* behavior of course, but presumably guaranteeing 
>>> no undefined behavior rules out large classes of problems, including many 
>>> security holes.  Now suppose you decide to be responsible and add some 
>>> asserts to help you catch bugs during development.  Hopefully they help you 
>>> catch all the bugs, but what if they don’t?  All of a sudden, if you still 
>>> have a bug when you ship, you now have undefined behavior.  As much as I’m 
>>> a fan of assertions having optimization benefits, It seems a little 
>>> perverse that using them could make shipping code less secure.
>> 
>> Yes, I agree.  -O should not imply undefined behavior in the case of an 
>> assert() predicate being dynamically false.
>> 
>> It sounds like we just need a documentation update here?
> 
> I’m pretty sure the documentation reflects assumptions that the optimizer is 
> already taking advantage of, but the performance team knows for sure.
> 
> -Dave
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for associated 
type declarations” begins now and runs through Wednesday, January 6th. The 
proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.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 Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you 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 


Cheers,
Doug Gregor
Review Manager

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

[swift-evolution] Customized Inline Init Closure

[Weston Catron via swift-evolution]

Ability to write an initializer while initializing an object.

Example

let name = “John Apple”;
let person = Person {
self.name = nameInput.first() + " " + nameInput.last()
self.dob = dateInput.datetime()
If (self.age() > 18) {
self.taxableStatus = INDEPENDANT
} else {
self.taxableStatus = DEPENDANT
}
};

Helpful examples: Objects with many required parameters that are defaulted in 
the initializers. 

SKLabelNode

let label = SKLabelNode(text: "Example") 
label.position = CGPoint(x: 0, y: 250); 
label.fontSize = 34; 
label.fontColor = UIColor.blackColor() 
self.addChild(label);

Can become:

let label = SKLabelNode(text: self.package!.title) {
self.position = CGPoint(x: 0, y: 250)
self.fontSize = 34
self.fontColor = UIColor.blackColor() 
}
self.addChild(label)

Readability Instead of a large amount of code setting up temporary variables to 
pass into an initializer, all initializing code could be wrapped in a closure.

Flexibility Instead of exhaustive initializers covering many use cases. Simpler 
initializers can be extended as needed. This can also encourage required 
properties over optional ones that are immediately defined. 

Compiler Warnings Closures react the same as initializers within classes, 
warning users of incomplete implementation of required properties.

Possible disadvantages:

Sloppy Coding Instead of writing complete initializers programmers can just 
rely on in-line initializers.  

Tried Before I found this feature is also available in C# 
(https://msdn.microsoft.com/en-us/library/bb397680.aspx 
). Not sure if it was 
helpful then but many languages since don't appear to use it. 

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Brent Royal-Gordon via swift-evolution]

> If I don’t sound sympathetic, it’s because nobody has shown a use-case for 
> this functionality, and until I see one I am going to have a hard time 
> believing there’s a problem worth solving.  If you want to make the case that 
> we need something like this, please show me why. 

Didn't this thread start off with a use case?

seq.lazy.filter(predicate).first// is not actually 
lazy, and Swift provides no good way to do this

One way to fix this is to add `first` to `SequenceType`, but it feels strange 
for a property to potentially consume part of the sequence. `buffered` 
ultimately has the same problem. By representing this as a function, it at 
least looks like something that might have side effects.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [SR-119] AnySequence --> Any*Collection promotion

[Austin Zheng via swift-evolution]

Hello all,

Currently there exist at least four 'type-erased' sequence/collection types: 
AnySequence, AnyForwardCollection, AnyBidirectionalCollection, and 
AnyRandomAccessCollection.

The three Any*Collection types can be conceptually arranged into a 'ladder', in 
which collections can be constructed unconditionally from collection types 
above themselves, and conditionally from collection types below themselves. 
I've put together a little ASCII image of this here: 
(https://gist.github.com/austinzheng/829425242bef1573b668 
).

Note that AnySequence doesn't currently fit into this ladder: Any*Collection 
instances can't easily be constructed from AnySequences. SR-119 
(https://bugs.swift.org/browse/SR-119 ) 
aims to change that. As per that ticket, I propose that we add three promotion 
APIs, sketched out as following:

extension AnyForwardCollection {
init?(_: AnySequence< Element>)
}

extension AnyBidirectionalCollection {
init?(_: AnySequence< Element>)
}

extension AnyRandomAccessCollection {
init?(_: AnySequence< Element>)
}

Like their Any*Collection --> Any*Collection antecedents, these initializers 
construct a new Any*Collection out of an existing AnySequence, but only if the 
underlying sequence is compatible, and without copying the underlying sequence.

I'll also have to examine SE-0014 
(https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md
 
)
 more closely to see if it has any effects on this proposal.

I plan on submitting a formal proposal at some point (probably by the end of 
the coming week), but first wish to solicit feedback, opinions, concerns, etc. 
Thanks for your time.

Best,
Austin___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add syntactic sugar for iterating over an Optional

[Tyler Cloutier via swift-evolution]

The syntax could be
for x in array? {

}

It wouldn't necessarily be consistent with 

if let foo = foo {

}

But as I've mentioned in another thread regarding the if let syntax and 
variable shadowing, it would probably make more sense to new users if the if 
let syntax was the following.

if let foo = foo? {

}

The ? is always used to conditionally unwrap optionals. It strikes me as odd 
that they are not used to unwrap them in control flow statements. 

i.e. Why should 

array?.forEach

be any different than,

for x in array?


Tyler

> On Dec 20, 2015, at 12:15 PM, Marco Masser via swift-evolution 
>  wrote:
> 
> I have to admit that Radek’s comment about “for … in? …” meaning an iteration 
> over a SequenceType containing Optional Values is valid.
> 
> But I think “for? … in …” is worse because it separates the “?” from the 
> thing that is the Optional thing. Consider:
> 
> for? x in array { … }
> 
> vs.
> 
> for x in? array { … }
> 
> If any of these two is about iterating over an Optional, it’s 
> the second one – at least to me. The first one reads much more like the “x” 
> could be optional.
> 
> Marco
> 
> 
>> On 2015-12-18, at 22:24, Radosław Pietruszewski via swift-evolution 
>>  wrote:
>> 
>> That’s… definitely an improvement as far as ambiguity is concerned, but I 
>> still don’t believe it passes the usefulness threshold, and I don’t really 
>> like the precedent of having a `for?`…
>> 
>> PS. FWIW, I like the spirit of the proposal, just not this solution. I’m all 
>> for “expressivity enhancements” — little things that helps me write cleaner 
>> code and express my intention better. But this doesn’t seem worth the 
>> trouble of extending the language.
>> 
>> — Radek
>> 
>>> On 18 Dec 2015, at 22:20, Jacob Bandes-Storch  wrote:
>>> 
>>> How about `for? object in array` instead?
>>> 
>>> On Fri, Dec 18, 2015 at 1:13 PM, Paul Cantrell via swift-evolution 
>>>  wrote:
> `for object in? array` … suggests that there’s something optional about 
> checking for inclusion, not about the array itself. It could easily be 
> interpreted as “iterate for all non-nil elements of array (where array: 
> [T?])” — a use case arguably more common than this.
 
 
 That’s a really good point.
 
 P
 
 
> On Dec 18, 2015, at 3:06 PM, Radosław Pietruszewski  
> wrote:
> 
> Personally, I’m -1 for the proposal. I see this as a solution to a very 
> minor, fairly rare, and not generalizable problem.
> 
> Perhaps more importantly: the syntax is confusing to my eyes. `for object 
> in? array` doesn’t immediately convey its semantics to me. It suggests 
> that there’s something optional about checking for inclusion, not about 
> the array itself. It could easily be interpreted as “iterate for all 
> non-nil elements of array (where array: [T?])” — a use case arguably more 
> common than this.
> 
> In the vast majority of cases, arrays shouldn’t be optional in the first 
> place. It’s rare that there’s a semantic difference between “empty array” 
> and “no array”.
> 
>> Sure, in that example it’s quite simple. It’s not the “?? []” syntax 
>> itself, which is perfectly clear; it’s having that dangling off the end 
>> of some longer expression. In real-world context, it does become 
>> additional noise.
> 
> That is a good point, albeit one that’s more broad than that — I dislike 
> how `as?` often forces me to add additional parentheses — and not strong 
> enough to warrant an introduction of a new `in?` construct IMHO.
> 
> — Radek
> 
>>> On 18 Dec 2015, at 21:56, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Dec 17, 2015, at 4:08 AM, Jeremy Pereira 
  wrote:
 
 
 On 16 Dec 2015, at 19:52, Paul Cantrell via swift-evolution 
  wrote:
 
 I do this a lot:
 
for object in array ?? [] {
 
 …and it does impair readability a bit at times.
>>> 
>>> Does it? It seems fairly understandable to me even though I have never 
>>> seen it before.
>> 
>> Sure, in that example it’s quite simple. It’s not the “?? []” syntax 
>> itself, which is perfectly clear; it’s having that dangling off the end 
>> of some longer expression. In real-world context, it does become 
>> additional noise.
>> 
>>> I think there is a good reason for keeping this construct a bit 
>>> “clunky”. Generally APIs give you a nil array for one of two reasons:
>>> 
>>> - there was some sort of error in retrieving the elements
>>> - there were no qualifying elements found.
>> 
>> You’re forgetting the third case, the most common one: things not 
>> populated / initialized yet. In that case, we often just want to leave a 
>> UI blank, for example, and doing nothing is the right behavior.
>> 
>> Doing nothing 

Re: [swift-evolution] Proposal: Add SequenceType.first

[Kevin Ballard via swift-evolution]

On Sat, Jan 2, 2016, at 07:17 PM, Dave Abrahams wrote:
>> But since it's a CollectionType, you need to preserve the ability to
>> access older values.
>
> Not once you replace it with a slice of itself.

Ah I see, I missed that subtlety. Or more specifically, when you first
said "slice" I was thinking of the Slice struct, but if you implement
slicing by hand then you can do this just fine.

>> So the only way to actually have this be a CollectionType is to
>> buffer the entire sequence up to the highest-accessed index.
>>
>> Of course, your use-case of processing a stream with some amount of
>> lookahead and throwing away the old data actually sounds like
>> something a "BufferedSequence" might provide. Or actually, a
>> "BufferedGenerator", because the only way to process a sequence is
>> with a generator and so all a "BufferedSequence" would really do is
>> just give you a "BufferedGenerator" from its generate() method.
>
> I’m quite certain this is buildable.  I’ve got my hands full at the
> moment or I’d create a prototype…

Now that I realize exactly what you meant, it should indeed be
buildable. Though short of requiring the user to provide it, I'm not
sure how to pick an appropriate chunk size.

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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[David Owens II via swift-evolution]

Seems like a good start for Swift developers that need to write some C code for 
their project. 

-David

Sent from my iPhone

> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add SequenceType.first

[Dave Abrahams via swift-evolution]

> On Dec 31, 2015, at 3:20 PM, Kevin Ballard  wrote:
> 
> On Thu, Dec 31, 2015, at 02:03 PM, Dave Abrahams wrote:
>>  
>>> On Dec 31, 2015, at 1:58 PM, Kevin Ballard >> > wrote:
>>>  
>>> Good idea, though I'd probably call it PeekSequence because it would only 
>>> buffer a single element (and BufferedSequence sounds like it's got an 
>>> arbitrary-sized buffer). Perhaps more useful would be the associated 
>>> PeekGenerator, because peek() is a useful thing to have when writing custom 
>>> generator-using code.
>>  
>> The size of the buffer is an implementation detail, and I don’t find “peek” 
>> descriptive.
>  
> There's precedent for the name "peek". More importantly, that's the name 
> you'd use for the generator method; the sequence would still have the "first" 
> property.
>  
> My concern with making the size of the buffer be an implementation detail is 
> I'd rather not add array allocation if I only need a single element of 
> lookahead. I suppose it could have an `enum { OneElement(Element), 
> Buffer([Element]) }` as the storage, but that still does end up being a 
> little bit of extra work on every call to next().
>  
>>> I'll write up a more detailed email with a proposed design in a minute.
>>>  
 Another related adapter I’d like to add is a model of CollectionType that 
 is backed by a sequence and lazily populated in fixed-sized chunks.
>>>  
>>> Also a good idea. Although really it could just be backed by a 
>>> ContiguousArray, those things already grow in chunks. I'll write up a 
>>> design for that too.
>>  
>> Not unless you want to keep the buffers alive longer than necessary.  
>> Imagine you’re parsing a long stream with some amount of lookahead.  You can 
>> scan this collection by slicing it and the buffer segments that are no 
>> longer in use will be automatically collected.
>  
> Ah, I didn't realize you wanted to collect chunks that haven't been used 
> lately. But I don't think that's possible;

> since it's backed by a sequence, the chunks MUST be generated in order; 
> there's no way to skip ahead, and no way to generate an older chunk that 
> you've thrown away.

Right…?

> But since it's a CollectionType, you need to preserve the ability to access 
> older values.

Not once you replace it with a slice of itself.

> So the only way to actually have this be a CollectionType is to buffer the 
> entire sequence up to the highest-accessed index.
>  
> Of course, your use-case of processing a stream with some amount of lookahead 
> and throwing away the old data actually sounds like something a 
> "BufferedSequence" might provide. Or actually, a "BufferedGenerator", because 
> the only way to process a sequence is with a generator and so all a 
> "BufferedSequence" would really do is just give you a "BufferedGenerator" 
> from its generate() method.

I’m quite certain this is buildable.  I’ve got my hands full at the moment or 
I’d create a prototype…

-Dave

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Dave Abrahams via swift-evolution]

> On Jan 2, 2016, at 12:13 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> Why should we absolutely add methods with unclear meanings or behavior, when 
>> there are already perfectly clear, if verbose, alternatives? 
>> seq.generate().next() may not be nice, but no one can get fooled by it.
> 
> Well, for one thing, because it doesn't work. You can't call a mutating 
> method directly on a return value without assigning it to a variable first. 
> And put simply, a temporary variable seems a bridge too far to me.

For a possibly-mutating operation, I think it’s perfectly appropriate that you 
have to create an intermediate variable.  If you want to create an extension 
with a “func possiblyConsumeFirst() -> Generator.Element”, you are welcome to 
do so; that’s what extensions are for.  IMO the standard library should not 
hide volatile sequence consumption under a property access.

If I don’t sound sympathetic, it’s because nobody has shown a use-case for this 
functionality, and until I see one I am going to have a hard time believing 
there’s a problem worth solving.  If you want to make the case that we need 
something like this, please show me why. 

-Dave

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Kevin Ballard via swift-evolution]

On Sat, Jan 2, 2016, at 12:13 PM, Brent Royal-Gordon wrote:
> > Why should we absolutely add methods with unclear meanings or behavior, 
> > when there are already perfectly clear, if verbose, alternatives? 
> > seq.generate().next() may not be nice, but no one can get fooled by it.
> 
> Well, for one thing, because it doesn't work. You can't call a mutating 
> method directly on a return value without assigning it to a variable first. 
> And put simply, a temporary variable seems a bridge too far to me.

Exactly. If `seq.generate().next()` worked, I'd be perfectly happy with that. 
I'd be tempted to submit a proposal saying this should be legal, but I believe 
that disallowing mutating methods on temporaries is an intentional decision 
that was intended to prevent the user from writing code that looks like it's 
mutating something that it isn't.

For example, given the following interface:

struct Foo {
var ary: [Int] { get }
}

Allowing mutating of temporaries would let me write code like

func foo(x: Foo) -> Int? {
return x.ary.popLast()
}

and yet this won't actually mutate the array at all (and it will incur an 
unwanted copy of the array storage that is immediately thrown away).

We could try and come up with some workaround, like maybe an attribute on 
`mutating func next()` that says "this may be called on a temporary", but it 
seems kind of hacky. And I can't think of anything other than 
`GeneratorType.next` that actually wants this behavior anyway (the closest 
alternative I can think of is passing a scalar as an UnsafePointer or 
UnsafeMutablePointer to a C function where you don't actually care about the 
output, where in C you can actually say something like `&(int){42}` if you 
want, but I haven't actually hit that case in Swift yet and it's pretty rare 
anyway).

Incidentally, the same rule is also what prohibits arrays from being passed to 
an inout parameter where a downcast is required. Arrays implicitly downcast as 
needed to simulate covariance on its element type, e.g. if U <: T then [U] can 
be used where a [T] is expected because an implicit downcasted copy is made. 
But you cannot pass a [U] to a function that expects an inout [T] because 
temporaries are immutable (and implicit array conversion produces a temporary).

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Chris Lattner via swift-evolution]

> On Jan 2, 2016, at 2:48 PM, Thorsten Seitz  wrote:
> 
> One question just occurred to me: do we really need the keyword „memberwise“ 
> anymore? Wouldn’t just using "init(…)“ be sufficient?

It wouldn’t be necessary to make the parser work, but I think we’d want 
something to make it clear what was intended.  Otherwise, you could write:

init(a : Int, …) 

when you meant:
init(a : Int …)

and unfortunate things would happen.  The memberwise keyword also makes it much 
more clear to the reader what is going on.

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

Re: [swift-evolution] Better syntax for deferred?

[Robert S Mozayeni via swift-evolution]

(Sorry if you get this email twice, I realized I first sent it from an email 
address that is not the one I used to subscribe to this list)

Not only that, but placing defer at the end of a scope, where any other code 
may never get executed if there’s an early return, kind of violates the whole 
concept of control flow.

func f() throws {
let o = file(path: "")
o.openFile()
do {
try o.write(self.data)
}

print("success")
always { o.close() }
}

What happens if o.write fails? Going with always would imply that we either…

A) put the `always` in every possible place the scope might exit, defeating the 
whole purpose of defer/always. Maury, I’m assuming you’re not actually 
suggesting that, which would leave: B) if the main scope of the function exits 
at any point, drop down to the `always` at the end of the scope and execute it. 
But then, what about the surrounding code at the end of the main scope? Like I 
said, I think this would violate the whole concept of control flow by 
cherry-picking a specific type of command that is always executed within a 
scope, even if that command is in some place the control flow doesn’t reach.

Unless I’m misinterpreting something (let me know if I am) this seems less 
intuitive than `defer` was to begin with.

-Robert

> On Jan 2, 2016, at 3:17 PM, Dennis Lysenko via swift-evolution 
>  wrote:
> 
> Deferring at the end of the function removes the ability to defer actions on 
> variables introduced in an inner scope.
> 
> 
> On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I have the terrible feeling something is wrong with my posts so that they get 
> caught by spamfilters or similar…
> 
> But as others stated as well:
> defer has a use case that is a little bit different from what you want to 
> archive.
> 
> > Why not use a solution that is widely used and better?
> I'm curious:
> Which languages have this "always" construct?
> ___
> 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] Better syntax for deferred?

[Developer via swift-evolution]

-1. `defer` doesn’t exist just to execute code at the end of blocks, it exists 
to allow resource cleanup when you have a function with multiple return points 
or non-trivial scoping.  For example, let’s add an if statement to your code:


func clear() {
   print("1")
   print("3")
   if (theBusiness) {
   print(“4”)
   return
   }
   always { print("2") }
}

Now `always` does not, in fact, model the flow of control through this function 
and I’m confused about where that finalizer is going to run.  I mean, because 
it is declared below the if, will it never execute?  Will it always execute as 
the name implies?  But couldn’t control flow branch before that statement is 
hit?  It’s a context switch I don’t have to make with `defer` as it currently 
stands.

> On Jan 2, 2016, at 7:25 AM, Maury Markowitz via swift-evolution 
>  wrote:
> 
> I'm confused about 'defer'. Not the purpose, the chosen syntax. 
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Thorsten Seitz via swift-evolution]

One question just occurred to me: do we really need the keyword „memberwise“ 
anymore? Wouldn’t just using "init(…)“ be sufficient?

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

Re: [swift-evolution] Better syntax for deferred?

[Charles Srstka via swift-evolution]

> On Jan 2, 2016, at 8:37 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> 
>> Unless I missed something obvious, wouldn't placing "code that always has to 
>> run at the end" actually *at the end* not make more sense? Like this…
> In most cases, you use defer for cleanup tasks - so it make more sense to 
> keep it at the source of the "problem":
> 
> file.open(); defer { file.close() }
> …
> 
> Tino

This. It’s way easier to remember to do necessary cleanup tasks if you add the 
cleanup call right after the call that requires the cleanup. It’s also much 
easier to catch cases where someone has forgotten to do so. Separating the init 
and cleanup by large distances as in the old try/catch/finally mechanism makes 
it easier for things to get out of sync as the code evolves.

Charles

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

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Tyler Cloutier via swift-evolution]

Please see comments inline.

> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> So “try” instead of “do”. If there is no catch, then just use braces 
>>> without a keyword for a block. 
>>> 
>>> And use do-while instead of repeat-while.
> 
> +1
> 
>> 
>> Do you also propose no longer marking calls to throwing functions with `try`?
> 
> If try had both a single-statement/expression form as it does today, and a 
> block form that makes it unnecessary to mark all the individual statements in 
> the block, that would be an improvement.
> 
>> Have you read the "Error-Handling Rationale" document in the Swift 
>> repository? If not, please do: 
>>  
>> If so, please explain why you disagree with it.
> 
> There are large classes of programs where you can know you don’t care exactly 
> where a failure happens, e.g. (most init functions, all pure functions, any 
> function that doesn’t break invariants).  In these cases marking every 
> statement or expression that can throw is just noise.  Try writing some 
> serialization/deserialization code where the underlying stream can fail to 
> see what I mean; you’ll have “try” everwhere, and it adds nothing to 
> comprehensibility or maintainability.  Personally I would like to be able to 
> label the function itself and not have to introuce a scope, but IMO being 
> able to create “try blocks” would be a welcome addition and would even match 
> the common case in blocks with catch clauses, where being aware of the exact 
> line where the error was generated is typically not useful.

I had proposed something very similar to this around six months ago on the 
swift-users list, but I think John McCall, had some (quite valid) concerns with 
this.

Unfortunately I can't access those emails, but I think his concern was that the 
purpose of try was to mark explicitly which statements throw and this would 
defeat the purpose of that. People might just wrap large blocks in try.

Another idea is to treat the block as an unnamed, no argument, no return value, 
function that could throw. This solves the problem in a very general way, and 
would retain the marking of all throwing functions with try, but has the 
perhaps unfortunate syntax of allowing things like:

try {
try myFunction()
} catch {

}

Something like this could be shortened to a consistent theoretical inline try 
catch syntax like:

try myFunction() catch {

}

Though, as John, pointed out at the time, this could still be added on with the 
current syntax. Obviously treating a try like an unnamed function would have 
different return semantics, so perhaps that's not the right abstraction. 
(Although I recall a thread going on that is considering allowing functions to 
retain return semantics of the outer scope)

Tyler


> 
> -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] Asserts should not cause undefined behaviour

[Joseph Lord via swift-evolution]

> On Jan 2, 2016, at 5:39 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 31, 2015, at 1:56 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution 
>>>  wrote:
 The documented behaviour of assert and assertionFailure in "disable safety 
 checks" builds (still documented as -Ounchecked) is that the compiler "may 
 assume that it would evaluate to true" or in the assertionFailure case 
 never be called.
>>> 
>>> Right.
>>> 
 This documented behaviour would allow the compiler to completely eliminate 
 tests and branches before or after the assertion and take the operation 
 deep into undefined behaviour.
>>> 
>>> Only in cases where the assertion would have failed, right?  The point of 
>>> -Ounchecked is that - if your code was correct with the checks - that it 
>>> will still be correct.  Disabling overflow and array bounds checks is far 
>>> more dangerous than the assertion behavior you cite here.
>>> 
 It appears from the code as if the assumption is not currently applied on 
 the assert method although it is on the assertionFailure case by means of 
 the _conditionallyUnreachable() call. assert seems to be a no-op in both 
 normal release and disable safety checks build modes.
>>> 
>>> Right.
>>> 
 [Proposed Change]
 
 Change the documentation for assert and assertionFailure so that behaviour 
 in unchecked mode is the same as in normal release - no evaluation and no 
 effect.
>>> 
>>> Why? :
>>> 
 1) Expected behaviour based on other languages is for assert to have no 
 effect in release. (If current behaviour is highly desired another 
 function name should be used). Having potential dangerous behaviour from a 
 function that is familiar across languages and is regarded as a safety 
 feature is undesirable.
>>> 
>>> This is the C model, but as you know, there is a whole field of custom 
>>> assertions libraries that people have developed.  I don’t think there is 
>>> anything like consensus on this topic.
>>> 
 2) Adding asserts to code should not make the code more dangerous whatever 
 the build. Assuming the truth of the assert may lead to runtime safety 
 checks being skipped and undefined behaviour when a no-op would be a safe 
 behaviour.
>>> 
>>> This only affects code built with -Ounchecked, which is definitely not a 
>>> safe mode to build your code.  The intention of this mode is that you can 
>>> use it to get a performance boost, if you believe your code to be 
>>> sufficiently tested.  This mode, which isn’t the default in any way, 
>>> intentionally takes the guard rails off to get better performance.
>>> 
>>> If you don’t like that model, don’t use this mode.
>> 
>> Let’s just consider -O; I think I understand Joseph’s objection here, and it 
>> seems valid.
>> 
>> Normally in -O, we say that if you stay in the “safe subset” of Swift code, 
>> you never get undefined behavior, even if there’s a bug in your code.  You 
>> might get *unpredictable* behavior of course, but presumably guaranteeing no 
>> undefined behavior rules out large classes of problems, including many 
>> security holes.  Now suppose you decide to be responsible and add some 
>> asserts to help you catch bugs during development.  Hopefully they help you 
>> catch all the bugs, but what if they don’t?  All of a sudden, if you still 
>> have a bug when you ship, you now have undefined behavior.  As much as I’m a 
>> fan of assertions having optimization benefits, It seems a little perverse 
>> that using them could make shipping code less secure.
> 
> Wait a sec; I just read the doc comments for assert over again.  They don’t 
> say there’s undefined behavior in -O if the condition isn’t satisfied.  So 
> now I don’t understand what Joseph is complaining about.  assert in -O is 
> documented to act exactly as C’s assert would with NDEBUG #defined.
> 
> -Dave

Thanks for the responses. 

The behaviour and documentation at -O is fine. My worry is only for unchecked 
builds. 

My concern is only for the unchecked behaviour. I still think it is surprising 
that adding an assert can substantively change the behaviour (undefined if 
false condition occurs). If assert was a brand new idea that did not exist in 
other languages It would be absolutely appropriate behaviour for the word as it 
is now but with the history of assert in other languages I still have two 
problems based on my understanding of asserts across languages. 

1) Adding asserts should never be able to add bugs (which they can do in 
unchecked code).
2) The stdlib assert cannot be used to handle any errors that may potentially 
occur and are handled but that you want to be informed of during development if 
there is any possibility that the code will ever be compiled in unchecked mode. 

T

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Drew Crawford via swift-evolution]

Thanks for directing me to this, I missed it.

> Most projects will not conform to these conventions.

Giggle.  Kind of an understatement, no?

Like, okay.  Here is a project I'd like to package.  (Read: I do package it, 
with features not in mainline swiftPM.)  https://github.com/jedisct1/libsodium 


Let's take a look at how this package realistically builds:

* It has tests ("make check")
* It has various --enable-foo flags
* It swaps in special implementations depending on if you have AMD64 

 or AVX instructions 

 or SSE2 

 etc.
* The optimization level is tuned on a per-architecture basis 

* They build (also) on Windows.  They're not changing how they're packaged for 
"SwiftPM, the Mac/Linux build system".
* Oh and this is cryptography code.  Do you *really* want to touch it?

I think an important feature of any C target proposal is that there will 
actually exist C targets which can be built under the proposal.  Until there 
are C people coming out of the woodwork saying "sure, I will repackage my 
software this way" I think the entire value is debatable.

Getting signoff from libdispatch/CoreFoundation is necessary but not sufficient 
to clear that hurdle.  I would think getting the other C deps in our own 
project family to repackage would be "table stakes" for any new C build system. 
 The real test are projects that are third-party and less friendly.

And I do not see realistically how we are ever going to support a project like 
libsodium, except calling out to automake.  An automake solution coincidentally 
supports both libdispatch and CoreFoundation right now.  IMO something like 
that is a much, much better direction in the short-term, and once we have done 
the first step of "packaging" those software via automake we will have "real" C 
projects in our package manager and we can design our C support around the 
concerns of real projects instead of imaginary ones.

> On Jan 2, 2016, at 11:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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

Re: [swift-evolution] Better syntax for deferred?

[Dennis Lysenko via swift-evolution]

Deferring at the end of the function removes the ability to defer actions
on variables introduced in an inner scope.

On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> I have the terrible feeling something is wrong with my posts so that they
> get caught by spamfilters or similar…
>
> But as others stated as well:
> defer has a use case that is a little bit different from what you want to
> archive.
>
> > Why not use a solution that is widely used and better?
> I'm curious:
> Which languages have this "always" construct?
> ___
> 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: Add SequenceType.first

[Brent Royal-Gordon via swift-evolution]

> Why should we absolutely add methods with unclear meanings or behavior, when 
> there are already perfectly clear, if verbose, alternatives? 
> seq.generate().next() may not be nice, but no one can get fooled by it.

Well, for one thing, because it doesn't work. You can't call a mutating method 
directly on a return value without assigning it to a variable first. And put 
simply, a temporary variable seems a bridge too far to me.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Félix Cloutier via swift-evolution]

This sounds interesting. I don't have time to read it right now but I like the 
idea and I'll give better feedback later.

Félix

> Le 2 janv. 2016 à 12:28:10, Kostiantyn Koval via swift-evolution 
>  a écrit :
> 
> Hi, Happy 2016. 
> 
> The proposal looks great as for me. Very nice starting point to add C family 
> support
> 
> Best Regards,
> Kostiantyn
> 
>> On 02 Jan 2016, at 18:00, Daniel Dunbar via swift-build-dev 
>>  wrote:
>> 
>> Happy 2016!
>> 
>> I am working on an initial proposal for adding support for C language 
>> targets to the Swift package manager, and am interested in feedback:
>> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
>> 
>> Some TL;DR:
>> - The proposal defines a basic convention for pure C language targets (no 
>> Swift/C mix and match, but other Swift targets can use the C targets).
>> - This is just intended to be the minimal initial feature, there will be a 
>> lot of add on work which I expect should be tackled in follow on 
>> PRs/proposals.
>> - The proposal doesn't try and outline every single nitty detail (e.g., 
>> exactly what C++ standard we will compile with). My intention is to pick a 
>> sensible default at implementation time and refine incrementally.
>> 
>> Unless there are serious objections, I am hoping to hope to land this 
>> proposal soon and start work on the feature shortly after.
>> 
>> Cheers,
>> - Daniel
>> 
>> 
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
> 
> ___
> 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: Add SequenceType.first

[Félix Cloutier via swift-evolution]

No one appears to have considered the C# example yet. In C#, IEnumerable 
(Swift's SequenceType) has a `First()` (and `FirstOrDefault(T)`) method.

C# also has a coroutine syntax (`yield return xyz`) that makes it easy to 
create sequences that are evaluated with side effects. However, Googling "c# 
ienumerable first", nobody seems to be wondering if the sequence will be 
evaluated multiple times. This true even though C# has a coroutine syntax that 
makes it very easy to create sequences with side effects.

I'm not passionate about whether a `first` property on sequences needs to feel 
"part of the language" (since that's what the stdlib is about), or how it 
should behave exactly. However, off the list into the world of making programs, 
it doesn't appear to matter much whether using `first` successively evaluates 
the sequence multiple times or not. If it needs to be evaluated just once, 
there are trivial ways to make that happen.

(I don't think that the observation can be extended to a lot of other sequence 
methods. This is about the specific case of `first`.)

Félix

> Le 2 janv. 2016 à 08:53:39, Gwendal Roué via swift-evolution 
>  a écrit :
> 
> The best interface is no interface, isn’t it? Why should we absolutely add 
> methods with unclear meanings or behavior, when there are already perfectly 
> clear, if verbose, alternatives? seq.generate().next() may not be nice, but 
> no one can get fooled by it.
> 
> Maybe we should discuss use cases, instead of "completing" a standard lib 
> that did not ask anything. It never stops: shouldn’t we add isEmpty to 
> SequenceType, if first was added? With the same ambiguity in both meaning and 
> behavior...
> 
> Indeed I agree that the buffered sequence is much more interesting, and that 
> it overlaps with the implicit enhancement request behind SequenceType.first. 
> I have one experience where I wanted to know whether a sequence was empty 
> before consuming it, and a standard buffered sequence would have been a much 
> welcomed tool.
> 
> Gwendal
> 
>> Le 2 janv. 2016 à 13:42, Brent Royal-Gordon via swift-evolution 
>>  a écrit :
>> 
>> May I suggest a simple solution?
>> 
>>  extension SequenceType {
>>  /// Returns one element from the beginning of the sequence, or 
>> `nil` if the sequence is empty.
>>  /// If `self` is a single-pass sequence, this may consume the 
>> element.
>>  func one() -> Generator.Element? {
>>  var generator = generate()
>>  return generator.next()
>>  }
>>  }
>> 
>> This should probably be a method in the protocol, and CollectionType should 
>> have an override which calls `first`.
>> 
>> The BufferedSequence stuff suggested elsewhere is probably useful too, and 
>> should be considered in addition to this, but I think this would cover the 
>> most common case.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Better syntax for deferred?

[Tino Heth via swift-evolution]

I have the terrible feeling something is wrong with my posts so that they get 
caught by spamfilters or similar…

But as others stated as well:
defer has a use case that is a little bit different from what you want to 
archive.

> Why not use a solution that is widely used and better?
I'm curious:
Which languages have this "always" construct?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Michel Fortin via swift-evolution]

Le 2 janv. 2016 à 13:29, Maury Markowitz via swift-evolution 
 a écrit :

> No, they don't. With the exception of "Go", I'm unfamiliar with any other 
> language that implements this feature *in this fashion*.

D has `scope (exit)`, which is exactly the same as `defer` in Swift.

It's also common to see C++ code using scope guards (implemented as a library 
feature). As far as I'm aware, this is where the pattern emerged first.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] Better syntax for deferred?

[Michel Fortin via swift-evolution]

Le 2 janv. 2016 à 9:25, Maury Markowitz via swift-evolution 
 a écrit :

> I'm confused about 'defer'. Not the purpose, the chosen syntax. 
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.

With your proposal, code like this:

func test() throws -> T {
let a = try makeSomething()
defer { a.cleanup() }

let b = try makeSomething()
defer { b.cleanup() }

return try compute(a, b)
}

would have to be rewritten somewhat like this:

func test() throws -> T {
let a = try makeSomething()
do {
let b = try makeSomething()
do {
return try compute(a, b)
always { b.cleanup() }
}
always { a.cleanup() }
}
}

which is a bit inconvenient. One important thing with `defer` is that where you 
put it in the function impacts at which point it gets pushed on the "cleanup 
stack", something that gets lost with `always` and which I need to add back 
through `do {}` blocks here.

I think what you are looking for is a `do {} finally {}` block, which you 
should feel free to propose if you think it's worth it. I personally don't 
think it makes the above example better, but it certainly has the benefit of 
always running things in source order.

func test() throws -> T {
let a = try makeSomething()
do {
let b = try makeSomething()
do {
return try compute(a, b)
} finally {
b.cleanup()
}
} finally {
a.cleanup()
}
}

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 1:26 PM, Javier Soto  wrote:
> 
> How would always behave if the function has an early return?

Exactly the same way as 'defer' would behave if the function has an early 
return.

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

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 12:56 PM, Tim Hawkins  wrote:
> 
> Again my 2 cents
> 
> Other languages use "deffer", and have very simular semantics

No, they don't. With the exception of "Go", I'm unfamiliar with any other 
language that implements this feature *in this fashion*.

> there is no benifit gained from being different, and it makes peoples task of 
> transfering from other systems easier.

Precisely why I make this suggestion. Swift is the oddball here, using 
something that is decidedly non-standard as well as confusing. Why not use a 
solution that is widely used and better?

> What is there works just fine and achives the result it was designed to do. 
> Why do we need to change it?

The same could be said for Obj-C, yet here we are.

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

Re: [swift-evolution] Better syntax for deferred?

[Javier Soto via swift-evolution]

How would always behave if the function has an early return? Like so:

func testAlways(x: Int) {
print("non-deferred call")
return
let a = 3
always {
print("deferred call: \(a)")
}
}
On Sat, Jan 2, 2016 at 9:56 AM Tim Hawkins via swift-evolution <
swift-evolution@swift.org> wrote:

> Again my 2 cents
>
> Other languages use "deffer", and have very simular semantics, there is no
> benifit gained from being different, and it makes peoples task of
> transfering from other systems easier.
>
> The percieved "simplicity" of the alternative semanatics and naming is
> subjective. What is there works just fine and achives the result it was
> designed to do. Why do we need to change it?
> On Jan 3, 2016 1:47 AM, "Maury Markowitz via swift-evolution" <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jan 2, 2016, at 11:48 AM, Sebastian Mecklenburg via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s
>> just what it does. And the deferred calls are not always necessary so they
>> can’t always be placed at the end.
>>
>> Can you be more specific about "deferred calls are not always necessary"?
>> Do you mean that you could, for instance, place an if in front of the
>> defer? If so one could do the same with always, of course. I'll use your
>> example, slightly expanded, to illustrate
>>
>> > func testDefer(x: Int) {
>> >defer {print("deferred call1")}
>> >if x > 1 { defer {print("deferred call2")} }
>> print("non-deferred call")
>> > }
>>
>> I would rewrite this as:
>>
>> func testAlways(x: Int) {
>> print("non-deferred call")
>> always {
>> print("deferred call1")
>> if x > 1 print("deferred call2")
>> }
>> }
>>
>> Which is 100% equivalent to your example, but works precisely as you
>> would expect without needing to "be aware" of any "logical consequence"s.
>> The code runs exactly as it appears.
>>
>> ___
>> 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
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Tim Hawkins via swift-evolution]

Again my 2 cents

Other languages use "deffer", and have very simular semantics, there is no
benifit gained from being different, and it makes peoples task of
transfering from other systems easier.

The percieved "simplicity" of the alternative semanatics and naming is
subjective. What is there works just fine and achives the result it was
designed to do. Why do we need to change it?
On Jan 3, 2016 1:47 AM, "Maury Markowitz via swift-evolution" <
swift-evolution@swift.org> wrote:

>
> > On Jan 2, 2016, at 11:48 AM, Sebastian Mecklenburg via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s
> just what it does. And the deferred calls are not always necessary so they
> can’t always be placed at the end.
>
> Can you be more specific about "deferred calls are not always necessary"?
> Do you mean that you could, for instance, place an if in front of the
> defer? If so one could do the same with always, of course. I'll use your
> example, slightly expanded, to illustrate
>
> > func testDefer(x: Int) {
> >defer {print("deferred call1")}
> >if x > 1 { defer {print("deferred call2")} }
> print("non-deferred call")
> > }
>
> I would rewrite this as:
>
> func testAlways(x: Int) {
> print("non-deferred call")
> always {
> print("deferred call1")
> if x > 1 print("deferred call2")
> }
> }
>
> Which is 100% equivalent to your example, but works precisely as you would
> expect without needing to "be aware" of any "logical consequence"s. The
> code runs exactly as it appears.
>
> ___
> 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] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 11:48 AM, Sebastian Mecklenburg via swift-evolution 
>  wrote:
> 
> I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s just 
> what it does. And the deferred calls are not always necessary so they can’t 
> always be placed at the end.

Can you be more specific about "deferred calls are not always necessary"? Do 
you mean that you could, for instance, place an if in front of the defer? If so 
one could do the same with always, of course. I'll use your example, slightly 
expanded, to illustrate

> func testDefer(x: Int) {
>defer {print("deferred call1")}
>if x > 1 { defer {print("deferred call2")} }
print("non-deferred call")
> }

I would rewrite this as:

func testAlways(x: Int) {
print("non-deferred call")
always {
print("deferred call1")
if x > 1 print("deferred call2")
}
}

Which is 100% equivalent to your example, but works precisely as you would 
expect without needing to "be aware" of any "logical consequence"s. The code 
runs exactly as it appears.

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

Re: [swift-evolution] Asserts should not cause undefined behaviour

[Dave Abrahams via swift-evolution]

> On Dec 31, 2015, at 1:56 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution 
>>  wrote:
>>> The documented behaviour of assert and assertionFailure in "disable safety 
>>> checks" builds (still documented as -Ounchecked) is that the compiler "may 
>>> assume that it would evaluate to true" or in the assertionFailure case 
>>> never be called.
>> 
>> Right.
>> 
>>> This documented behaviour would allow the compiler to completely eliminate 
>>> tests and branches before or after the assertion and take the operation 
>>> deep into undefined behaviour.
>> 
>> Only in cases where the assertion would have failed, right?  The point of 
>> -Ounchecked is that - if your code was correct with the checks - that it 
>> will still be correct.  Disabling overflow and array bounds checks is far 
>> more dangerous than the assertion behavior you cite here.
>> 
>>> It appears from the code as if the assumption is not currently applied on 
>>> the assert method although it is on the assertionFailure case by means of 
>>> the _conditionallyUnreachable() call. assert seems to be a no-op in both 
>>> normal release and disable safety checks build modes.
>> 
>> Right.
>> 
>>> [Proposed Change]
>>> 
>>> Change the documentation for assert and assertionFailure so that behaviour 
>>> in unchecked mode is the same as in normal release - no evaluation and no 
>>> effect.
>> 
>> Why? :
>> 
>>> 1) Expected behaviour based on other languages is for assert to have no 
>>> effect in release. (If current behaviour is highly desired another function 
>>> name should be used). Having potential dangerous behaviour from a function 
>>> that is familiar across languages and is regarded as a safety feature is 
>>> undesirable.
>> 
>> This is the C model, but as you know, there is a whole field of custom 
>> assertions libraries that people have developed.  I don’t think there is 
>> anything like consensus on this topic.
>> 
>>> 2) Adding asserts to code should not make the code more dangerous whatever 
>>> the build. Assuming the truth of the assert may lead to runtime safety 
>>> checks being skipped and undefined behaviour when a no-op would be a safe 
>>> behaviour.
>> 
>> This only affects code built with -Ounchecked, which is definitely not a 
>> safe mode to build your code.  The intention of this mode is that you can 
>> use it to get a performance boost, if you believe your code to be 
>> sufficiently tested.  This mode, which isn’t the default in any way, 
>> intentionally takes the guard rails off to get better performance.
>> 
>> If you don’t like that model, don’t use this mode.
> 
> Let’s just consider -O; I think I understand Joseph’s objection here, and it 
> seems valid.
> 
> Normally in -O, we say that if you stay in the “safe subset” of Swift code, 
> you never get undefined behavior, even if there’s a bug in your code.  You 
> might get *unpredictable* behavior of course, but presumably guaranteeing no 
> undefined behavior rules out large classes of problems, including many 
> security holes.  Now suppose you decide to be responsible and add some 
> asserts to help you catch bugs during development.  Hopefully they help you 
> catch all the bugs, but what if they don’t?  All of a sudden, if you still 
> have a bug when you ship, you now have undefined behavior.  As much as I’m a 
> fan of assertions having optimization benefits, It seems a little perverse 
> that using them could make shipping code less secure.

Wait a sec; I just read the doc comments for assert over again.  They don’t say 
there’s undefined behavior in -O if the condition isn’t satisfied.  So now I 
don’t understand what Joseph is complaining about.  assert in -O is documented 
to act exactly as C’s assert would with NDEBUG #defined.

-Dave

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

Re: [swift-evolution] Asserts should not cause undefined behaviour

[Dave Abrahams via swift-evolution]

> On Jan 2, 2016, at 2:57 AM, Arnold  wrote:
> 
> 'assert' evaluates the condition and aborts only in Odebug builds.
> 
> 'precondition' evaluates the condition and aborts also in optimized -0 builds.
> 
> As far as I remember  the decision was made to give it this semantics to 
> mimic C's assert() function.
> 
> If an abort is desired in optimized builds one should use 'precondition’.

Thanks, Arnold, but this doesn’t address the key question: in -O builds, does 
the optimizer make optimizations based on the assumption that asserts would not 
fire if they were enabled?

> 
> Sent from my iPhone
> 
>> On Jan 2, 2016, at 8:27 AM, Dave Abrahams  wrote:
>> 
>> 
 On Jan 1, 2016, at 11:25 PM, Chris Lattner  wrote:
 
 On Dec 31, 2015, at 1:56 PM, Dave Abrahams  wrote:
>> 2) Adding asserts to code should not make the code more dangerous 
>> whatever the build. Assuming the truth of the assert may lead to runtime 
>> safety checks being skipped and undefined behaviour when a no-op would 
>> be a safe behaviour.
> 
> This only affects code built with -Ounchecked, which is definitely not a 
> safe mode to build your code.  The intention of this mode is that you can 
> use it to get a performance boost, if you believe your code to be 
> sufficiently tested.  This mode, which isn’t the default in any way, 
> intentionally takes the guard rails off to get better performance.
> 
> If you don’t like that model, don’t use this mode.
 
 Let’s just consider -O; I think I understand Joseph’s objection here, and 
 it seems valid.
>>> 
>>> Ah, good point.
>>> 
 Normally in -O, we say that if you stay in the “safe subset” of Swift 
 code, you never get undefined behavior, even if there’s a bug in your 
 code.  You might get *unpredictable* behavior of course, but presumably 
 guaranteeing no undefined behavior rules out large classes of problems, 
 including many security holes.  Now suppose you decide to be responsible 
 and add some asserts to help you catch bugs during development.  Hopefully 
 they help you catch all the bugs, but what if they don’t?  All of a 
 sudden, if you still have a bug when you ship, you now have undefined 
 behavior.  As much as I’m a fan of assertions having optimization 
 benefits, It seems a little perverse that using them could make shipping 
 code less secure.
>>> 
>>> Yes, I agree.  -O should not imply undefined behavior in the case of an 
>>> assert() predicate being dynamically false.
>>> 
>>> It sounds like we just need a documentation update here?
>> 
>> I’m pretty sure the documentation reflects assumptions that the optimizer is 
>> already taking advantage of, but the performance team knows for sure.
>> 
>> -Dave
>> 

-Dave

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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Kostiantyn Koval via swift-evolution]

Hi, Happy 2016. 

The proposal looks great as for me. Very nice starting point to add C family 
support

Best Regards,
Kostiantyn

> On 02 Jan 2016, at 18:00, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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

[swift-evolution] [swiftpm] Add proposal for C language support

[Daniel Dunbar via swift-evolution]

Happy 2016!

I am working on an initial proposal for adding support for C language targets 
to the Swift package manager, and am interested in feedback:
  
https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md

Some TL;DR:
 - The proposal defines a basic convention for pure C language targets (no 
Swift/C mix and match, but other Swift targets can use the C targets).
 - This is just intended to be the minimal initial feature, there will be a lot 
of add on work which I expect should be tackled in follow on PRs/proposals.
 - The proposal doesn't try and outline every single nitty detail (e.g., 
exactly what C++ standard we will compile with). My intention is to pick a 
sensible default at implementation time and refine incrementally.

Unless there are serious objections, I am hoping to hope to land this proposal 
soon and start work on the feature shortly after.

Cheers,
 - Daniel


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

Re: [swift-evolution] Better syntax for deferred?

[Sebastian Mecklenburg via swift-evolution]

I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s just 
what it does. And the deferred calls are not always necessary so they can’t 
always be placed at the end.

The only thing to be aware of is that the order is reversed (or not 
determined), so

func testDefer() {
defer {print("deferred call1")}
defer {print("deferred call2")}
}

prints

deferred call2
deferred call1

But I think that is the logical consequence of the way how defer is supposed to 
work, so that’s OK too. One just has to be aware of it.

> On 02 Jan 2016, at 15:25, Maury Markowitz via swift-evolution 
>  wrote:
> 
> I'm confused about 'defer'. Not the purpose, the chosen syntax. 
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.
> 
> 
> ___
> 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] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen  wrote:
> 
> Defer is used to make code *always* run, even if the function terminates 
> early. Imagine:

Which is precisely why I called it 'always'. So in your example:

func doSomethingWith(x: Int) {
print(“1”)
defer { print(“2") }
if x > 3 { defer { print(“yay”); return }
print(“3”)
}

I would say:

func doSomethingWith(x: Int) {
print(“1”)
print(“3”)
always {
print(“2")
if x > 3 { print(“yay”) }
}
}

This is functionally identical, but both the syntax and program flow are 
greatly improved.

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

Re: [swift-evolution] Inquiry: Status of SR-122 ?

[Dmitri Gribenko via swift-evolution]

On Sat, Jan 2, 2016 at 4:53 AM, Dave Abrahams via swift-evolution
 wrote:
>
>> On Jan 1, 2016, at 4:34 PM, plx via swift-evolution 
>>  wrote:
>>
>> I was preparing a proposal-sketch relating to this earlier discussion: 
>> http://article.gmane.org/gmane.comp.lang.swift.evolution/1629
>>
>> …which is largely about inserting "intermediate steps” between 
>> `SequenceType` and `CollectionType`, but to get the full benefit would 
>> likely wind up requiring modifications to the API on the `*Index` types 
>> (e.g. `ForwardIndexType`, which at present is required of a 
>> `CollectionType`’s `Index`).
>>
>> Searching for prior discussion/work I found this bug: 
>> https://bugs.swift.org/browse/SR-122 , and was curious if anything further 
>> has happened on that topic?
>
> Yes, Dmitri has been making progress on an implementation.  He may be able to 
> point you at it…

The prototype is checked in at
test/Prototypes/CollectionsMoveIndices.swift, feel free to ask me more
questions about it.

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] Better syntax for deferred?

[Nicky Gerritsen via swift-evolution]

Defer is used to make code *always* run, even if the function terminates early. 
Imagine:

func doSomethingWith(x: Int) {
print(“1”)
defer { print(“2") }
if x > 3 { defer { print(“yay”); return }
print(“3”)
}

Now print(“2”) will always happen, even if the if is true. Placing it at the 
end this will not be the case. The “yay” will only be printed in the case of 
the if.
In general we can not place the defer at the end, because it only should run if 
the code “comes by” the call.

Regards,

Nicky

> On 2 jan. 2016, at 15:25, Maury Markowitz via swift-evolution 
>  wrote:
> 
> I'm confused about 'defer'. Not the purpose, the chosen syntax.
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Tino Heth via swift-evolution]

> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this…
In most cases, you use defer for cleanup tasks - so it make more sense to keep 
it at the source of the "problem":

file.open(); defer { file.close() }
…

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

[swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

I'm confused about 'defer'. Not the purpose, the chosen syntax. 

func confusing() {
print("1")
defer { print("2") }
print("3")
}

Produces 1,3,2. Trying to describe what is happening here is non-trivial... it 
runs line 1, then we put line 2 on a stack, then line three runs, then we pop 
the stack... what?! And stepping through it in the debugger... ugh.

Unless I missed something obvious, wouldn't placing "code that always has to 
run at the end" actually *at the end* not make more sense? Like this...

func clear() {
print("1")
print("3")

always { print("2") }
}

Not only is the code clearly expressing its intent, the actual execution is 
following the source.


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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Gwendal Roué via swift-evolution]

The best interface is no interface, isn’t it? Why should we absolutely add 
methods with unclear meanings or behavior, when there are already perfectly 
clear, if verbose, alternatives? seq.generate().next() may not be nice, but no 
one can get fooled by it.

Maybe we should discuss use cases, instead of "completing" a standard lib that 
did not ask anything. It never stops: shouldn’t we add isEmpty to SequenceType, 
if first was added? With the same ambiguity in both meaning and behavior...

Indeed I agree that the buffered sequence is much more interesting, and that it 
overlaps with the implicit enhancement request behind SequenceType.first. I 
have one experience where I wanted to know whether a sequence was empty before 
consuming it, and a standard buffered sequence would have been a much welcomed 
tool.

Gwendal
 
> Le 2 janv. 2016 à 13:42, Brent Royal-Gordon via swift-evolution 
>  a écrit :
> 
> May I suggest a simple solution?
> 
>   extension SequenceType {
>   /// Returns one element from the beginning of the sequence, or 
> `nil` if the sequence is empty.
>   /// If `self` is a single-pass sequence, this may consume the 
> element.
>   func one() -> Generator.Element? {
>   var generator = generate()
>   return generator.next()
>   }
>   }
> 
> This should probably be a method in the protocol, and CollectionType should 
> have an override which calls `first`.
> 
> The BufferedSequence stuff suggested elsewhere is probably useful too, and 
> should be considered in addition to this, but I think this would cover the 
> most common case.
> 
> -- 
> 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] Proposal: Add SequenceType.first

[Brent Royal-Gordon via swift-evolution]

May I suggest a simple solution?

extension SequenceType {
/// Returns one element from the beginning of the sequence, or 
`nil` if the sequence is empty.
/// If `self` is a single-pass sequence, this may consume the 
element.
func one() -> Generator.Element? {
var generator = generate()
return generator.next()
}
}

This should probably be a method in the protocol, and CollectionType should 
have an override which calls `first`.

The BufferedSequence stuff suggested elsewhere is probably useful too, and 
should be considered in addition to this, but I think this would cover the most 
common case.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Susan Cheng via swift-evolution]

Consider this,

struct RandomGenerator : GeneratorType, SequenceType {



mutating func next() -> UInt32? {

return arc4random()

}

}

what's the expected result of follows??


let random = RandomGenerator()


let resultA = random.first

let resultB = random.first

let resultC = Array(random.prefix(4))

let resultD = Array(random.prefix(4))

all should agree that resultC and resultD will get different array. what's
about with resultA and resultB?

Gwendal Roué  於 2016年1月2日 下午8:13 寫道：

Hello,

My two cents: I feel uncomfortable with SequenceType.first since
SequenceType clearly states that it may be destructed on iteration.

Compare :

seq.generate().next() // clear that it may give another result if called
twice
seq.first // unclear that it may give another result if called
twice

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Gwendal Roué via swift-evolution]

Hello,

My two cents: I feel uncomfortable with SequenceType.first since SequenceType 
clearly states that it may be destructed on iteration.

Compare :

seq.generate().next() // clear that it may give another result if called twice
seq.first // unclear that it may give another result if called twice

Gwendal

> Le 31 déc. 2015 à 00:57, Kevin Ballard via swift-evolution 
>  a écrit :
> 
> It's sometimes useful to get the first element of a sequence. To that end I'd 
> like to propose
>  
> extension SequenceType {
> /// Returns the first element of `self`, or `nil` if `self` is empty.
> /// - Complexity: O(1)
> var first: Self.Generator.Element? {
> var gen = generate()
> return gen.next()
> }
> }
>  
> I think it makes sense to add this property to the definition of SequenceType 
> as well, so various sequences can override it to avoid constructing a 
> generator.
>  
> With this added to SequenceType, we can remove it from CollectionType, as the 
> behavior will be the same.
>  
> -Kevin Ballard
> 
> ___
> 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] Asserts should not cause undefined behaviour

[Kevin Ballard via swift-evolution]

On Fri, Jan 1, 2016, at 11:58 PM, Kevin Ballard wrote:
> On Fri, Jan 1, 2016, at 11:25 PM, Chris Lattner via swift-evolution wrote:
> > > On Dec 31, 2015, at 1:56 PM, Dave Abrahams  wrote:
> > >>> 2) Adding asserts to code should not make the code more dangerous 
> > >>> whatever the build. Assuming the truth of the assert may lead to 
> > >>> runtime safety checks being skipped and undefined behaviour when a 
> > >>> no-op would be a safe behaviour.
> > >> 
> > >> This only affects code built with -Ounchecked, which is definitely not a 
> > >> safe mode to build your code.  The intention of this mode is that you 
> > >> can use it to get a performance boost, if you believe your code to be 
> > >> sufficiently tested.  This mode, which isn’t the default in any way, 
> > >> intentionally takes the guard rails off to get better performance.
> > >> 
> > >> If you don’t like that model, don’t use this mode.
> > > 
> > > Let’s just consider -O; I think I understand Joseph’s objection here, and 
> > > it seems valid.
> > 
> > Ah, good point.
> > 
> > > Normally in -O, we say that if you stay in the “safe subset” of Swift 
> > > code, you never get undefined behavior, even if there’s a bug in your 
> > > code.  You might get *unpredictable* behavior of course, but presumably 
> > > guaranteeing no undefined behavior rules out large classes of problems, 
> > > including many security holes.  Now suppose you decide to be responsible 
> > > and add some asserts to help you catch bugs during development.  
> > > Hopefully they help you catch all the bugs, but what if they don’t?  All 
> > > of a sudden, if you still have a bug when you ship, you now have 
> > > undefined behavior.  As much as I’m a fan of assertions having 
> > > optimization benefits, It seems a little perverse that using them could 
> > > make shipping code less secure.
> > 
> > Yes, I agree.  -O should not imply undefined behavior in the case of an 
> > assert() predicate being dynamically false.
> > 
> > It sounds like we just need a documentation update here?
> 
> assert() and assertionFailure() are already explicitly documented as doing 
> nothing in -O builds, and only making the assumption that the condition is 
> always true/function is never called in -Ounchecked builds.
> 
> As far as I can tell, the only actual inaccuracy in the documentation is the 
> fact that assert() claims that the optimizer may assume the condition is 
> always true in -Ounchecked when it doesn't seem to actually do that (because 
> it doesn't do anything at all when not using -Onone). Both assert() and 
> assertionFailure() do nothing in -O, which matches the documentation.

Having said that, it occurs to me that maybe the optimizer is actually 
specially detecting the call to assert() under -Ounchecked, but from the source 
of assert() there's nothing there to indicate that it actually makes any 
assumptions under -Ounchecked.

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