[swift-evolution] [Proposal] Tuple Extensions

[Developer via swift-evolution]

I’ve been contemplating this idea for a while now, mostly because I think it’s 
a very important feature, but also because I can’t find a single example of a 
programming language getting it completely right.  In Swift, the motif of 
tuples throughout the language would lead one to think that they have some kind 
of special status in the language.  Yet, tuples are an opaque concept exposed 
by the compiler to the end user with no opportunity for extension.  Languages 
that have tried to expose tuples to their users for extension have done so in 
less than ideal ways (see Tuple1-Tuple22 Scala 
, 
Haskell 
’s hard 
limit on tuples, Rust ’s 
limitations for std::tuple), yet each implementation has something to offer a 
possible Swift implementation.  I see only one course of action that will bring 
us extensible tuples in a manner that is compatible with Swift and its overall 
design philosophy.  To that end, I have drawn up a draft proposal 
 for generic 
tuple extensions that I will submit to swift-evolution shortly.

All the best,

~Robert Widmann




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] Move where clause to end of declaration

[Developer via swift-evolution]

Hi there, just wanted to let you know I have a name!  It's unfortunate that the 
mailing list won't accept the update I've made (this has been the 3rd-ish time 
I've tried).

~Robert Widmann

2016/05/02 3:16、David Hart  のメッセージ:

> Hello swift-evolution,
> 
> I took the pitch originally from Developer to move the where clause out of 
> the generic parameter list, with improvements brought up by Pyry Jahkola, and 
> wrote a proposal for it. I opened a Pull Request, but if anybody wants to 
> bring some modifications to it before it is merged, please let me know what 
> you think:
> 
> Move where clause to end of declaration
> Proposal: SE-
> Author(s): David Hart, Developer, Pry Jahkola
> Status: TBD
> Review manager: TBD
> Introduction
> 
> This proposal suggests moving the where clause to the end of the declaration 
> syntax, but before the body, for readability reasons. It has been discussed 
> at length on the following swift-evolution thread:
> 
> [Pitch] Moving where Clauses Out Of Parameter Lists
> 
> Motivation
> 
> The where clause in declarations can become quite long. When that happens, it 
> breaks the declaration syntax in two, hurting its readability. There is also 
> no good way of formatting the declaration syntax to make it much better.
> 
> Proposed solution
> 
> The proposal suggests moving the where clause at the end of the declaration, 
> but before the body of concerned declarations. With the proposed change, 
> where clauses do not impede the main declaration and are also more easily 
> formattable. For example, here is the same function declaration before and 
> after the change: 
> 
> func anyCommonElements T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element>(lhs: T, _ rhs: U) -> Bool 
> where
> {
> ...
> }
> 
> func anyCommonElements(lhs: T, _ rhs: U) 
> -> Bool where
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> }
> This proposal has no impact on extension declarations with constraints 
> because those declarations already have the where clauses right before the 
> body. In that regard, the proposal makes the other declarations more 
> consistent with extension declarations.
> 
> Detailed design
> 
> First of all, the grammar of generic-parameter-clause is modified to loose 
> the requirement- clause:
> 
> generic-parameter-clause → < generic-parameter-list >
> 
> The grammar of declarations are then amended to gain the requirement-clause: 
> 
> function-declaration → function-head function-name 
> generic-parameter-clauseopt function-signature requirement-clauseopt 
> function-bodyopt
> 
> union-style-enum → indirectopt enum enum-name  generic-parameter-clauseopt 
> type-inheritance-clauseopt requirement-clauseopt { 
> union-style-enum-membersopt }
> 
> raw-value-style-enum → enum enum-name generic-parameter-clauseopt 
> type-inheritance-clause requirement-clauseopt { raw-value-style-enum-members 
> *}*
> 
> struct-declaration → attributesopt access-level-modifieropt struct 
> struct-name generic-parameter-clauseopt type-inheritance-clauseopt 
> requirement-clauseopt struct-body
> 
> class-declaration → attributesopt access-level-modifieropt finalopt class 
> class-name generic-parameter-clauseopt type-inheritance-clauseopt 
> requirement-clauseopt class-body
> 
> protocol-method-declaration → function-head function-name 
> generic-parameter-clauseopt function-signature requirement-clauseopt
> 
> protocol-initializer-declaration → initializer-head 
> generic-parameter-clauseopt parameter-clause throwsopt requirement-clauseopt
> 
> protocol-initializer-declaration → initializer-head 
> generic-parameter-clauseopt parameter-clause rethrows requirement-clauseopt
> 
> initializer-declaration → initializer-head generic-parameter-clauseopt 
> parameter-clause throwsopt requirement-clauseopt initializer-body
> 
> initializer-declaration → initializer-head generic-parameter-clauseopt 
> parameter-clause rethrows requirement-clauseopt initializer-body
> 
> Impact on existing code
> 
> This proposal impacts all declarations which contain where clauses expect for 
> extension declarations and will therefore require a Fix-It. 
> 
> Alternatives considered
> 
> The first post in the swift-evolution thread originally proposed moving the 
> where clause just after the generic type declaration. Since then, the 
> original author and many other participants in the thread have agreed that 
> the current proposal is superior.
> 
> It was also proposed to remove the simple inheritance constraints from the 
> generic parameter list, but several arguments were brought up that it would 
> complicate declarations of simple generics which only needed inheritance 
> constraints.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

[Developer via swift-evolution]

Just a quick thought, but isn't this what NSArray is for?  If you know the type 
of a thing at runtime, it's probably best to use the part of the language that 
will help you most in that area: the Objective-C bridge.  

Doug is right that this is the shade of dependent types and would require a 
computation rule in the type system.  For example, what type does Array have 
here:

// In some far-off module

func DefeatOptimizer() -> Bool { return false }

// Back home again

var ty = Any.Type
for i in (0.. 
のメッセージ:

> Hi Doug
> 
>> In programming-language circles, this feature is called “dependent types” 
>> (see, e.g., https://en.wikipedia.org/wiki/Dependent_type), and it introduces 
>> significant complicates into a type system. For example, determining whether 
>> two types are equivalent becomes a run-time property rather than a 
>> compile-time property. I don’t know if Swift will end with a 
>> dependently-typed type system. To get there, we would need a number of very 
>> strongly-motivating use cases illustrating how common programming tasks can 
>> be improved with dependent types,  and we would need to solid plan for 
>> managing the complexity―both implementation complexity in the compiler’s 
>> type checker and also the language complexity seen by Swift user’s when they 
>> encounter this feature.
> 
> I must admit to being ever so slightly confused about your connection with 
> "dependent types"; in all my years of programming, I have never come across 
> the context of the expression as found in the article cited. Anything that 
> needs algebraic formulae to explain is far too complicated for mere mortal 
> programmers and I am willing to state that I certainly didn't understand more 
> than a few words.
> 
> All I am postulating is the ability to create instances of generic types, 
> bound to (a) parameter type(s) in the same manner as is currently possible 
> with non-generic types.
> 
> To bring it down to basics, take the example of wanting to create an array of 
> a given type of objects:
> 
>let aType: Any.Type = Int.self
> 
>var arr = [aType]
> 
> … creates an array of Any.type…
> 
>let aType: Any.Type = Int.self
> 
>var arr = [aType]()
> 
> … results in an error "Invalid use of '()' to call a value of non-function 
> type '[Any.Type]'"
> 
>let aType: Any.Type = Int.self
> 
>var arr = Array() 
> 
> … results in an error "'aType' is not a type"
> 
> 
> So, how are we meant to be able to create arrays, or any other generic type 
> that require to be bound to a type known only at runtime?
> 
> In C#, We have the Type class, which contains useful properties like 
> isGenericType, isConstructedGenericType and methods like 
> GetGenericArguments() and, most important to this use case, 
> MakeGenericType(Type []).
> 
> I would make a strong argument for completing Swift generics by including 
> such facilities in Any.Type, so that:
> 
> 1. we do not have to use the somewhat cumbersome Mirror mechanism
> 
> 2. we can do something useful with instances of Any.Type, which, at present, 
> does absolutely nothing.
> 
> Adding similar functionality to C#'s Type class to Any.Type would break 
> absolutely zero code but would make life a whole load easier for those of us 
> who are power users of generics. Otherwise, FMPOV, Swift generics are but a 
> pale imitation of the concept and very much second class citizens in the 
> language.
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Developer via swift-evolution]

+1.  The only times I've ever had to use this outside of HoFs were dirty, dirty 
hacks that probably should have used this anyway.  I can stomach an extra bit 
of syntax everywhere if it means removing an inconsistency in the wider 
language.

~Robert Widmann

2016/04/15 0:57、Chris Lattner via swift-evolution  
のメッセージ:

> We currently accept function type syntax without parentheses, like:
> 
>  Int -> Float
>  String -> ()
> 
> etc.  The original rationale aligned with the fact that we wanted to treat 
> all functions as taking a single parameter (which was often of tuple type) 
> and producing a tuple value (which was sometimes a tuple, in the case of void 
> and multiple return values).  However, we’ve long since moved on from that 
> early design point: there are a number of things that you can only do in a 
> parameter list now (varargs, default args, etc), implicit tuple splat has 
> been removed, and  the compiler has long ago stopped modeling function 
> parameters this way.  Beyond that, it eliminates one potential style war.
> 
> Given all this, I think it makes sense to go for syntactic uniformity between 
> parameter list and function types, and just require parenthesis on the 
> argument list.  The types above can be trivially written as:
> 
>  (Int) -> Float
>  (String) -> ()
> 
> Thoughts?
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Developer via swift-evolution]

Even better.  +1.

~Robert Widmann

2016/04/06 14:35、Pyry Jahkola via swift-evolution <swift-evolution@swift.org> 
のメッセージ:

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

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

[Developer via swift-evolution]

If you've ever gotten to the point where you have a sufficiently generic 
interface to a thing and you need to constrain it, possibly in an extension, 
maybe for a generic free function or operator, you know what a pain the syntax 
can be for these kinds of operations.  For example, the Swift book implements 
this example to motivate where clauses

func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool

This is noisy and uncomfortable to my eyes, and almost impossible to align 
correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
I'd like so see what the community feels about moving the where clause out of 
the angle brackets.  So that example becomes

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

Or, if you're feeling ambitious, even

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

Thoughts?

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Developer via swift-evolution]

To be fair, the "spirit of UIKit" that you mention comes from a time and 
language that encouraged OO and OO alone.  Optional methods are, more often 
than not, backed by gigantic bit fields that keep track of whether or not the 
delegate actually conforms to the entirety of a protocol, which opens up a huge 
vector for bugs and complicates the internal logic of the control.  I think 
Swift gives us a better opportunity to rethink the old approach not encourage 
it, don't you think?

For example, using a method returning an optional (or even better, a proper 
value) means you can give a proper semantics for what it means to not implement 
a particular method rather than "no selector here".  

~Robert Widmann

2016/03/31 14:49、Yuval Tal via swift-evolution  
のメッセージ:

> None taken. However, most of the delegate concept of UIKit relies heavily on 
> this "nonsensical" requirement. It is impossible for someone to implement a 
> control in swift which is "in the spirit" of UIKit, meaning the control has a 
> delegate, with several methods that share the same name with different 
> parameters, some are required and some are optional. I think it is not fair 
> to tell users that they cannot implement something that is such a common and 
> repeating pattern in the core. 
> 
>> On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Wed Mar 30 2016, Yuval Tal  wrote:
>> 
>> > Hi,
>> >
>> > I find that optional protocol methods to be very useful. However,
>> > there is a caveat -- it needs to be mapped to @objc.  This puts a set
>> > of limitations, such as: structures cannot be used as parameters as it
>> > does not map to objective-c. What do you think about removing the
>> > requirement of using @objc and allow to create optional methods
>> > without these limitations?
>> 
>> Caveat: this is going to be strongly-worded; sorry in advance.  I think
>> (no offense intended) it's a terrible idea.  The whole notion of an
>> “optional requirement” is nonsensical to begin with, and the use of
>> optional protocol requirements encourages a style of programming that
>> lifts the responsibility of the protocol designer for careful design at
>> the expense of clients of the protocol.  There are better ways to do
>> things; let's not propagate this anti-pattern any further than it's
>> already gone.
>> 
>> --
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

[Developer via swift-evolution]

+1

~Robert Widmann

2016/03/31 10:26、Jeff Kelley via swift-evolution  
のメッセージ:

> I have never taken advantage of this, personally. Given that there isn’t 
> anything that this feature enables that can’t be done if it’s removed―aside 
> from reordering arguments―I’d be in favor of removing it for simplicity’s 
> sake.
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
> 
>> On Mar 30, 2016, at 12:59 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> Many people are surprised when they find out defaulted parameters can be 
>> reordered, unlike required arguments. This special case adds complexity to 
>> the language, and runs against our general trend of treating argument labels 
>> as a significant part of an API's name, and preferring a single way of 
>> writing API calls. I think it's worth revisiting this design choice―is the 
>> special case worth the complexity? How many people take advantage of default 
>> argument reordering?
>> 
>> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Developer via swift-evolution]

> On Mar 30, 2016, at 4:35 PM, Ted F.A. van Gaalen <tedvgios...@gmail.com> 
> wrote:
> 
> 
>> On 30.03.2016, at 20:29, Developer <devteam.cod...@gmail.com 
>> <mailto:devteam.cod...@gmail.com>> wrote:
>> 
>> I believe section 6.3 of the ISO/C99 specification describes its integer 
>> promotion rules and Appendix J describes undefined behavior as a consequence 
>> of integer and floating point coercion.  I refer to these when I speak of 
>> "rules”.
> Although ISO compliance makes sense in a lot of cases, for programming 
> languages, 
> these rules are extremely bureaucratic, restricting and always far behind 
> fast developments in 
> IT.   Would you like to see Swift to be ISO compliant? 
> Then you could throw away perhaps more than half the language constructs
> currently present in Swift?
> 
> @Chris:  
> 
> is there a desire/requirement to make Swift ISO compliant? 
> and thus therewith restricting Swift’s flexibility? If so, to what extent? 
> 

This is orthogonal to the discussion at hand.

>> 
>> As long as data loss is an "unintended" effect of a certain class of 
>> coercions, I don't believe it deserves to be implicit.  If you "know what 
>> you're doing", the preference so far has been to tell the compiler that and 
>> use the constructors provided in the Swift Standard Library to perform 
>> explicit truncation.  Even in C, if you can be more specific with a cast in 
>> cases where you intend data loss, you probably should be.
> With all due respect, Robert, Imho, I find this all too theoretical and 
> bureaucratic and tons of unnecessary overhead. 
> and I am telling the compiler implicitly: 
> aFloat = anInt  // The compiler will use a builtin function to do the 
> conversion. what can be wrong with that? 
> Again, in the cases I mentioned there is no data loss. (precision excluded) 

An example of “data loss”, then (adapted from the wonderful example given by 
Felix Cloutier here <http://stackoverflow.com/a/2658736/945847>).  Be judicious 
running this, it will spin for quite a while if you don’t kill it first.

import Darwin

for i in Int(INT_MAX).stride(to: 0, by: -1) {
let value : Float = Float(i)
let ivalue : Int = Int(value)
if (i != ivalue) {
print("Integer \(i) is represented as \(ivalue) in a float\n")
}
}


You may still argue, however, that loss of precision is not as egregious as 
full-on truncation, but it is still data loss all the same.  If it is too 
technical and bureaucratic to insert casts to make your intent clear in either 
language (rather than what I assume is just silencing -Wconversion), I’ll take 
bureaucracy and safety over convenience please.

~Robert Widmann

>  
>> 
>> ~Robert Widmann
>> 
>> 2016/03/30 13:57、Ted F.A. van Gaalen <tedvgios...@gmail.com 
>> <mailto:tedvgios...@gmail.com>> のメッセージ:
>> 
>>> Thank you, Robert & Haravikk
>>> Please allow me to respond in-line hereunder, thanks.
>>> Ted.
>>>> On 30.03.2016, at 16:15, Haravikk <swift-evolut...@haravikk.me 
>>>> <mailto:swift-evolut...@haravikk.me>> wrote:
>>>> 
>>>> I’m in favour of implicit conversion for integers where no data can be 
>>>> lost (UInt32 to Int64, Int32 to Int64 etc.), in fact I posted a similar 
>>>> thread a little while ago but can’t find it; there’s something being done 
>>>> with numbers so this may be partly in the works.
>>>> 
>>>> I definitely think that implicit conversion for floating point should be 
>>>> avoided, as it can’t be guaranteed
>>> Why?  and   What cannot be guaranteed? 
>>> 
>>>> except in certain edge cases; for example, Javascript actually technically 
>>>> uses a double for all of its numeric types, effectively giving it a 52-bit 
>>>> (iirc) integer type,
>>> awful, didn’t know that
>>>> so in theory conversion of Int32 to Double is fine, and Int16 to Float 
>>>> might be as well, but I’m not certain if it’s a good idea or not, as it’s 
>>>> not quite the same as just extending the value.
>>> It simply would cause a float with less precision as an integer like 
>>> 1 -becomes e.g - .99, (depending on magnitude, of course) 
>>> but that is normal in a floating point domain; E.g.  also with: 
>>>  var v:Double  = 1.0   //   Double to Double 
>>> 
>>> v would have the same imprecision… and could be anywhere between 
>>> .9998…1.1  
>>> (rough estimation, depending on magnitude and 

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Developer via swift-evolution]

I believe section 6.3 of the ISO/C99 specification describes its integer 
promotion rules and Appendix J describes undefined behavior as a consequence of 
integer and floating point coercion.  I refer to these when I speak of "rules".

As long as data loss is an "unintended" effect of a certain class of coercions, 
I don't believe it deserves to be implicit.  If you "know what you're doing", 
the preference so far has been to tell the compiler that and use the 
constructors provided in the Swift Standard Library to perform explicit 
truncation.  Even in C, if you can be more specific with a cast in cases where 
you intend data loss, you probably should be.

~Robert Widmann

2016/03/30 13:57、Ted F.A. van Gaalen <tedvgios...@gmail.com> のメッセージ:

> Thank you, Robert & Haravikk
> Please allow me to respond in-line hereunder, thanks.
> Ted.
>> On 30.03.2016, at 16:15, Haravikk <swift-evolut...@haravikk.me> wrote:
>> 
>> I’m in favour of implicit conversion for integers where no data can be lost 
>> (UInt32 to Int64, Int32 to Int64 etc.), in fact I posted a similar thread a 
>> little while ago but can’t find it; there’s something being done with 
>> numbers so this may be partly in the works.
>> 
>> I definitely think that implicit conversion for floating point should be 
>> avoided, as it can’t be guaranteed
> Why?  and   What cannot be guaranteed? 
> 
>> except in certain edge cases; for example, Javascript actually technically 
>> uses a double for all of its numeric types, effectively giving it a 52-bit 
>> (iirc) integer type,
> awful, didn’t know that
>> so in theory conversion of Int32 to Double is fine, and Int16 to Float might 
>> be as well, but I’m not certain if it’s a good idea or not, as it’s not 
>> quite the same as just extending the value.
> It simply would cause a float with less precision as an integer like 
> 1 -becomes e.g - .99, (depending on magnitude, of course) 
> but that is normal in a floating point domain; E.g.  also with: 
>  var v:Double  = 1.0   //   Double to Double 
> 
> v would have the same imprecision… and could be anywhere between 
> .9998…1.1  
> (rough estimation, depending on magnitude and the floating point type used) 
> 
>> 
>>> On 30 Mar 2016, at 14:57, Developer via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> What you describe, all those cases where one fixes losing precision by 
>>> simply "ignoring it", that's part of why I'm hesitant about simply throwing 
>>> in C-like promotion rules into any language.
> 
> E.g. if I assign an Int to a Double, then I know very well what I am doing.
>  often occurring simple example here:
>   for i in 0..<10
> {
> dTemperature = dInterval * i / /   Double = Double * 
> Int  (not possible yet in Swift)
>foo(dTemperature)  
>  }
>  
>   Here I still have to write: 
>dTemperature = dInterval * Double(i)   
> 
>   However, Swift will accept: 
>dTemperature = dInterval * 3// 3 inferred to 
> Double. could be regarded as an implicit conversion? 
> 
>   
> 
>>>  Once you add implicit type coercions, even just between integer or 
>>> floating point types, your language gains a hundred unspoken rules
> Could you please explain these “unspoken rules” you mention more in detail?  
> 
>>> and little guard rails you have to cling to lest you slip and hit the next 
>>> pitfall.
> I am counting on the average intelligence of programmers.
> 
>>>  Though you may be dismissive of information loss, it is a serious issue in 
>>> coercions, and one with implications that are never completely grokked by 
>>> experts
> In practice, the implications/effects/behavior of a programming language 
> cannot be fully predicted and understood, there are simply too many 
> possibilities, 
> Functional Programming attempts to solve this, trying to make/do everything 
> mathematically 
> correct but fails for the aforementioned reason.
> 
>>> and serve as yet another hindrance to novices trying to adopt the language. 
> I don’t agree here. Even novices should have a good understanding 
> of the basic data types of a programming language,
> Also note that  concepts of integer, natural, rational, irrational numbers 
> etc.
> is very basic mathematics as learned in high school. 
> or your country’s equivalent education. 
> 
> 
> So aDouble = anInt  should -in the programmer’s mind- 
> appear as an explicit conversion, that is, he/she sh

Re: [swift-evolution] [Review] SE-0048: Generic Type Aliases

[Developer via swift-evolution]

What is your evaluation of the proposal?
+1.  Especially for forcing the alias side of the declaration to explicitly 
keep track of type constraints.

Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Previously, one could "work around" this by declaring a 0-case generic 
enum with associated type "projections".  I'm glad to see that pattern find a 
formal place in the language.

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

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
This proposal brings Swift up to par with languages that allow any kind of 
"alias"ing of types, whether that be C++ or Haskell [in a cleaner way than the 
former].

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
In-depth study.  I actually took a crack at an implementation a while ago!

~Robert Widmann

2016/03/24 12:54、Douglas Gregor via swift-evolution  
のメッセージ:

> Hello Swift community,
> 
> The review of SE-0048 "Generic Type Aliases" begins now and runs through 
> March 29, 2016. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
> Reply text
> 
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Keyword Discoverability

[Developer via swift-evolution]

Give escape a whack sometime.

~Robert Widmann

2016/01/04 3:43、John Joyce via swift-evolution  
のメッセージ:

> Hello all
> 
> It feels like Swift has some risk of going the direction of C++ at times. By 
> that I mean complexity creep. 
> Increasingly nuanced scoping results in more keywords and constructs. 
> Useful and good but increasingly complex and steepening learning curve. 
> 
> I'd like to kick off discussion of ways to increase discoverability. 
> 
> One thought is tools.  
> In thinking about contextual completions like Xcode's Open Quickly or the 
> universal field thing in Sublime, it sure seems like some way to invoke a 
> list of keywords and constructs available-in-the-current-scope would be 
> helpful. 
> 
> Thoughts ?
> 
> ___
> 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]: Free the '$' Symbol!

[Developer via swift-evolution]

Well, that's just it.  $ is a perfectly valid character in identifiers 
everywhere but in the grammar for operators for some reason.  It isn't 
reserved, it just isn't there.

~Robert Widmann

2016/01/03 0:53、Brent Royal-Gordon  のメッセージ:

>> 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] 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

[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] Self behaves inconsistently in protocol method signatures

[Developer via swift-evolution]

That doesn't look like a variance issue to me, that's about the same 
"information" invariant I talked about before.  The former works because self 
resolves to an invariant type, the type of the implementing structure, which 
satisfies the requirement Self introduces.  The latter does not because Self 
indicates a level of specificity C cannot guarantee.  Self is magic, but it is 
also implemented as a generic parameter.  So think of it this way:

protocol Q {
  func bar() -> T { return Q() }
}

You wouldn't expect that to compile, would you?

~Robert Widmann

2015/12/28 12:49、Matthew Johnson  のメッセージ:

> 
>> On Dec 28, 2015, at 11:19 AM, Developer  wrote:
>> 
>> My understanding of Self is that it is a special generic parameter resolved 
>> by the type system to the type of the implementing structure.  That 
>> resolution must be invariant because the implementing structure (here, 
>> non-final classes) can choose to yank the protocol's invariants out from 
>> under you when it is subclassed.  Sure, retroactively, you can make things 
>> conform, but you also can't completely guarantee type safety with any kind 
>> of variance in Self in all cases. 
>> 
>> On the other hand, using the protocol itself in either position says that 
>> you only wish to restrict yourself to the protocol itself, not some specific 
>> implementation.  You are necessarily specifying an upper bound (here C) on 
>> the amount of "information" you can get out of the type, so it is possible 
>> to introduce variance because you will never violate the protocol's 
>> invariants by returning a subtype with a legal conformance.
>> 
>> Self doesn't mean two different things, your protocol declarations do!
> 
> My mind must be a little bit foggy this morning.  This works:
> 
> extension C: Q {
> func bar() -> Self { return self }
> }
> 
> What doesn’t work, regardless of whether C is final or not, is this:
> 
> extension C: Q {
> // Cannot convert return expression of type ‘C’ to return type ‘Self'
> func bar() -> Self { return C() }
> }
> 
> In order for classes to meet a protocol requirement with Self in the return 
> position you must specify Self (rather than the conforming type) as the 
> return type for the method.  Self in the return position of a method is 
> treated as covariant.
> 
> In order for classes to meet a protocol requirement with Self in parameter 
> position you must specify the type of the conforming class (you cannot 
> specify Self in an argument position).  Obviously the type of the conforming 
> class is invariant.
> 
> This is the sense in which Self in protocol declarations is inconsistent.  
> The requirements on conforming types are different - invariance for Self 
> parameters and covariance for Self return types.
> 
> IMO it would be much more clear if this distinction was explicit rather than 
> implicit based on the location of Self.  It would also be extremely useful in 
> some cases to be able to specify an invariant `ConformingSelf` return type.
> 
> 
>> 
>> ~Robert Widmann
>> 
>> 2015/12/28 11:49、Matthew Johnson via swift-evolution 
>>  のメッセージ:
>> 
>>> I have brought up the idea of a non-covarying Self a few times.  
>>> 
>>> I was surprised to realize that Self is actually non-covarying when used 
>>> for parameters in protocol declarations!
>>> 
>>> Here is an example demonstrating this:
>>> 
>>> protocol P {
>>>func foo(s: Self)
>>> }
>>> protocol Q {
>>>func bar() -> Self
>>> }
>>> 
>>> class C: P {
>>>// this works!  Self as an argument type in the protocol declaration 
>>> does not covary
>>>func foo(c: C) {}
>>> }
>>> 
>>> class D: C {}
>>> 
>>> extension C: Q {
>>>// method ‘bar()’ in non-final class ‘C’ must return ‘Self’ to conform 
>>> to protocol ‘Q'
>>>func bar() -> C { return self } 
>>> }
>>> 
>>> 
>>> It doesn’t make sense to allow a co-varying Self for parameters so I can 
>>> understand how the current state might have arisen.  At the same time, 
>>> using Self to mean two different things is inconsistent, confusing and it 
>>> doesn’t allow us to specify a non-covarying Self as a return type in 
>>> protocol requirements.  
>>> 
>>> As I have pointed out before, the ability to specify a non-covarying Self 
>>> as a return type would make it possible to design a protocol that can be 
>>> retroactively conformed to by non-final classes (such as those in Apple’s 
>>> frameworks).
>>> 
>>> I think it would be a very good idea to introduce a non-covarying Self 
>>> which would specify the type that adds conformance to the protocol and 
>>> require this Self to be used in places where covariance is not possible, 
>>> such as parameter types.  It would also be allowed elsewhere, such as 
>>> return types, making it easier to conform non-final classes when covariance 
>>> is not required by the protocol.
>>> 
>>> One possible name is `ConformingSelf`.  One thing I like about 

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

[Developer via swift-evolution]

My understanding of Self is that it is a special generic parameter resolved by 
the type system to the type of the implementing structure.  That resolution 
must be invariant because the implementing structure (here, non-final classes) 
can choose to yank the protocol's invariants out from under you when it is 
subclassed.  Sure, retroactively, you can make things conform, but you also 
can't completely guarantee type safety with any kind of variance in Self in all 
cases. 

On the other hand, using the protocol itself in either position says that you 
only wish to restrict yourself to the protocol itself, not some specific 
implementation.  You are necessarily specifying an upper bound (here C) on the 
amount of "information" you can get out of the type, so it is possible to 
introduce variance because you will never violate the protocol's invariants by 
returning a subtype with a legal conformance.

Self doesn't mean two different things, your protocol declarations do!

~Robert Widmann

2015/12/28 11:49、Matthew Johnson via swift-evolution 
 のメッセージ:

> I have brought up the idea of a non-covarying Self a few times.  
> 
> I was surprised to realize that Self is actually non-covarying when used for 
> parameters in protocol declarations!
> 
> Here is an example demonstrating this:
> 
> protocol P {
>func foo(s: Self)
> }
> protocol Q {
>func bar() -> Self
> }
> 
> class C: P {
>// this works!  Self as an argument type in the protocol declaration does 
> not covary
>func foo(c: C) {}
> }
> 
> class D: C {}
> 
> extension C: Q {
>// method ‘bar()’ in non-final class ‘C’ must return ‘Self’ to conform to 
> protocol ‘Q'
>func bar() -> C { return self } 
> }
> 
> 
> It doesn’t make sense to allow a co-varying Self for parameters so I can 
> understand how the current state might have arisen.  At the same time, using 
> Self to mean two different things is inconsistent, confusing and it doesn’t 
> allow us to specify a non-covarying Self as a return type in protocol 
> requirements.  
> 
> As I have pointed out before, the ability to specify a non-covarying Self as 
> a return type would make it possible to design a protocol that can be 
> retroactively conformed to by non-final classes (such as those in Apple’s 
> frameworks).
> 
> I think it would be a very good idea to introduce a non-covarying Self which 
> would specify the type that adds conformance to the protocol and require this 
> Self to be used in places where covariance is not possible, such as parameter 
> types.  It would also be allowed elsewhere, such as return types, making it 
> easier to conform non-final classes when covariance is not required by the 
> protocol.
> 
> One possible name is `ConformingSelf`.  One thing I like about this name is 
> that it makes it very clear that it is the type that introduces protocol 
> conformance.
> 
> I’m interested in hearing thoughts on this.
> 
> Matthew
> ___
> 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] Beef up Imports

[Developer via swift-evolution]

The 'except' change is interesting, but it's still a context switch that can 
wind up confusing people.  I think that's partly why Agda has the 'renaming' 
operation separate in the first place.

~Robert Widmann

2015/12/27 10:30、T.J. Usiyan via swift-evolution <swift-evolution@swift.org> 
のメッセージ:

> import Foo using (bar, Baz, qux, waldo as fred)  // a "whitelist import"
> import Foo hiding (bar, Baz, qux, waldo as fred) // a "blacklist import"
> 
> 
> Is nice but `hiding… (waldo as fred)` is confusing. Am I hiding waldo? It is 
> also strange to look in that list for things that I am hiding and things that 
> I am importing. Context switches after the item that I am importing because 
> `as` follows the item in question.
> 
> import Foo (waldo as fred) using (bar, Baz, qux)  // a "whitelist import"
> import Foo (waldo as fred) hiding (bar, Baz, qux) // a "blacklist import"
> 
> `using` didn't actually need the syntax change but maintaining one consistent 
> form might be worth it. If not, `import Foo using (bar, Baz, waldo as fred)` 
> is fine. 
> 
> On Sun, Dec 27, 2015 at 7:44 AM, Pyry Jahkola via swift-evolution 
> <swift-evolution@swift.org> wrote:
>>> On 27 Dec 2015, at 07:12, Developer via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Therefore, I propose the introduction of 3 agda-esque operations for 
>>> imports to replace the usual `import 
>>> {func|typealias|struct|class|enum|etc.}` syntax:
>>> 
>>> • import Foo using (bar, Baz, qux, corge, …)
>>> • import Foo hiding (bar, baz, qux, corge, …)
>>> • import Foo renaming (grault to garply, waldo to fred, …)
>> 
>> +1, but why not just…?
>> 
>> import Foo using (bar, Baz, qux, waldo as fred)  // a "whitelist import"
>> import Foo hiding (bar, Baz, qux, waldo as fred) // a "blacklist import"
>> 
>> I've been able to work around identifier conflicts with the present import 
>> syntax but it gets clumsy with larger modules. I think both import-using and 
>> import-hiding would be very welcome in Swift, but the third notation made me 
>> double check its semantics from The Agda Wiki. Turns out the renaming (...) 
>> syntax is actually an extension to the other two and is often used as a part 
>> of the one or the other:
>> 
>> import Foo using (bar, Baz, qux) renaming (waldo to fred)
>> import Foo hiding (bar, Baz, qux) renaming (waldo to fred)
>> 
>> Why not do without renaming? Just allow both import-using and import-hiding 
>> to optionally rename imported identifiers. Further, while these keywords can 
>> and should be made context-specific, I think it's simplest to reuse "as" as 
>> the associating keyword.
>> 
>> That would lead us to the proposed syntax:
>> 
>> import Foo using (bar, Baz, qux, waldo as fred)  // a "whitelist import"
>> import Foo hiding (bar, Baz, qux, waldo as fred) // a "blacklist import"
>> 
>> where the tuple-like parentheses enclose a potentially empty list of 
>> identifiers or "identifier as identifier" mappings. The examples below 
>> should clarify the meaning and intended use of these two statements.
>> 
>>> Again, it should be obvious by uniqueness of identifiers what each one is 
>>> referencing, so qualification of each identifier is unnecessary.
>> 
>> 
>> Agreed. In addition, extending the import statement to class/enum/struct 
>> members doesn't make sense to me. Those don't conflict with the global scope 
>> at all.
>> 
>> — Pyry Jahkola
>> 
>> 
>> P.S. If this turns into a formal proposal, should we also address how 
>> imported operators should be dealt with? Can operators be selectively 
>> imported, hidden, or renamed? If renaming is made possible, we should be 
>> explicit on how the renamed operator inherits its associativity and 
>> precedence from the original one.
>> 
>> 
>> Examples
>> 
>> Suppose the module Foo contains the following identifiers:
>> 
>> // module Foo:
>> // - bar, Baz, qux, waldo
>> 
>> The "import-all" remains as it is in Swift 2:
>> 
>> import Foo
>> 
>> _ = (bar, Baz.self, qux, waldo) // All identifiers can be unqualified.
>> 
>> The "import-all" is synonymous with the longer "hide-nothing":
>> 
>> import Foo hiding ()
>> 
>> To hide or rename an identifier, fill in the parentheses:
>> 
>> import Foo hiding (Baz, waldo as fred)
>> 
>> _ =

Re: [swift-evolution] Lambda function syntax

[Developer via swift-evolution]

With a proper λ, that's the point.  The lambda calculus doesn't focus on the 
delimiter between the binder and the body because it isn't the important part 
of an abstraction, the rest is.  I would argue a programming language shouldn't 
either.  What is to be gained by having more syntax around a construct all 
about anonymity?

~Robert Widmann

2015/12/27 17:56、Alexander Regueiro  のメッセージ:

> It’s been agreed by almost everyone that “in” is at the very least a poor 
> delimiter. It’s barely noticeable.
> 
>> On 27 Dec 2015, at 22:54, Developer  wrote:
>> 
>> Hell, we have Unicode support, why not λ (U+03BB)?  Seriously though, for a 
>> C-like language I have to agree that Swift's approach is one of the best.  I 
>> can't think of a way of improving it that wouldn't immediately clash with 
>> the style and syntax of the language.  Sure you could change a few keywords 
>> here and there, but fundamentally 
>> 
>> { args in body } 
>> 
>> Strikes a balance between C-like basic blocks and Objective-C-like blocks.  
>> When you start making more of this implicit or shifting it around, you have 
>> to necessarily start caring about things like whitespace and implicit 
>> scoping (I notice in the example you give, it is immediately less clear 
>> which identifiers are bound into what block). Things I don't think Swift 
>> wants you to care about, or makes explicit where you should.  Losing a few 
>> characters here and there doesn't seem worth it to lose an equal amount of 
>> declarative-ness.
>> 
>> ~Robert Widmann
>> 
>> 2015/12/27 17:24、Brent Royal-Gordon via swift-evolution 
>>  のメッセージ:
>> 
 In this mail I’m answering several statements made in this thread by 
 different people, not only Brent’s mail from which I just picked the 
 following snippet:
 
> let names = people.map => person { person.name }
 
 For me that is more difficult to read than
 
  let names = people.map { person in person.name }
 
 Especially when chaining is used, i.e.
 
  let names = people.filter => person { person.isFriend }.map => person { 
 person.name }
 
 (or would I have to add parentheses somewhere with this proposed syntax?)
 
 vs.
 
  let names = people.filter { person in person.isFriend }.map { person in 
 person.name }
>>> 
>>> I said in the email that => is too visually heavy for this role.
>>> 
>>> Here's something lighter, although I'm still not satisfied with it, and not 
>>> seriously suggesting it:
>>> 
>>>  let names = people.map ~ person { person.name }
>>> 
>>> Or even:
>>> 
>>>  let names = people.map \person { person.name }
>>> 
>>> However, I'm really struggling to find anything that I actually like here. 
>>> This may be one of those cases where we dislike what's there and explore a 
>>> bunch of options, only to find out that the current thing actually is the 
>>> least bad alternative after all.
>>> 
>>> -- 
>>> 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] Lambda function syntax

[Developer via swift-evolution]

Now, now, that's no way to talk about a century's worth of computing research.

Since you have yet to respond to my original point, I'll expound:

I see Swift's choice of "in" in context of other programming languages that 
admit anonymous inner scopes with little fuss.  Those tend to come from the 
ML-family, which uses

// args in scope
let e = expr in body

Here, what is lacking is visibility of scope, but what is gained is 
composability.  Swift takes this a step further with

let e = { args in body }(expr)

Thus, coming from the C-side of things, you get nearly the same benefits as the 
former, but with the feel of a C-like language.  To change `in` or permute the 
ordering of binder, body, or delimiter detracts from Swift's position in either 
of these.

All the best,

~Robert Widmann

2015/12/27 18:07、Alexander Regueiro  のメッセージ:

> The lambda calculus is a mathematical tool. It’s not designed for 
> readability. Your point is invalid.
> 
>> On 27 Dec 2015, at 23:03, Developer  wrote:
>> 
>> With a proper λ, that's the point.  The lambda calculus doesn't focus on the 
>> delimiter between the binder and the body because it isn't the important 
>> part of an abstraction, the rest is.  I would argue a programming language 
>> shouldn't either.  What is to be gained by having more syntax around a 
>> construct all about anonymity?
>> 
>> ~Robert Widmann
>> 
>> 2015/12/27 17:56、Alexander Regueiro  のメッセージ:
>> 
>>> It’s been agreed by almost everyone that “in” is at the very least a poor 
>>> delimiter. It’s barely noticeable.
>>> 
 On 27 Dec 2015, at 22:54, Developer  wrote:
 
 Hell, we have Unicode support, why not λ (U+03BB)?  Seriously though, for 
 a C-like language I have to agree that Swift's approach is one of the 
 best.  I can't think of a way of improving it that wouldn't immediately 
 clash with the style and syntax of the language.  Sure you could change a 
 few keywords here and there, but fundamentally 
 
 { args in body } 
 
 Strikes a balance between C-like basic blocks and Objective-C-like blocks. 
  When you start making more of this implicit or shifting it around, you 
 have to necessarily start caring about things like whitespace and implicit 
 scoping (I notice in the example you give, it is immediately less clear 
 which identifiers are bound into what block). Things I don't think Swift 
 wants you to care about, or makes explicit where you should.  Losing a few 
 characters here and there doesn't seem worth it to lose an equal amount of 
 declarative-ness.
 
 ~Robert Widmann
 
 2015/12/27 17:24、Brent Royal-Gordon via swift-evolution 
  のメッセージ:
 
>> In this mail I’m answering several statements made in this thread by 
>> different people, not only Brent’s mail from which I just picked the 
>> following snippet:
>> 
>>> let names = people.map => person { person.name }
>> 
>> For me that is more difficult to read than
>> 
>> let names = people.map { person in person.name }
>> 
>> Especially when chaining is used, i.e.
>> 
>> let names = people.filter => person { person.isFriend }.map => person { 
>> person.name }
>> 
>> (or would I have to add parentheses somewhere with this proposed syntax?)
>> 
>> vs.
>> 
>> let names = people.filter { person in person.isFriend }.map { person in 
>> person.name }
> 
> I said in the email that => is too visually heavy for this role.
> 
> Here's something lighter, although I'm still not satisfied with it, and 
> not seriously suggesting it:
> 
> let names = people.map ~ person { person.name }
> 
> Or even:
> 
> let names = people.map \person { person.name }
> 
> However, I'm really struggling to find anything that I actually like 
> here. This may be one of those cases where we dislike what's there and 
> explore a bunch of options, only to find out that the current thing 
> actually is the least bad alternative after all.
> 
> -- 
> 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] Lambda function syntax

[Developer via swift-evolution]

Notation is not an arbitrary construct, and the choice of how to represent a 
λ-abstraction isn’t either.  When Church designed the calculus, he chose just 3 
simple constructs: variables, abstractions, and applications, to be the 
entirety of the language.  Readability in the system is derived from simplicity 
of notation and concept, not from syntactic noise - far removed from this 
system through decades of investigation and simplification by other logicians 
and combinatorists.

I chose my examples from languages that I believe stay truest to the original 
vision of a λ - Swift included - because I believe they best inform my argument 
that the syntax needn’t change to fit a particular style because it is, by some 
definitions, unreadable.  In fact, I find it to be just as readable, if not 
more, than the other languages I mentioned precisely because the existing 
syntax blends in so nicely with the goal of the past and the syntax we have 
now. 

I believe that in changing the ‘in’ keyword or the other ideas below amounts to 
little more than another permutation of syntax overtop an already good model.  
If anything, you really start to lose the original intent of closures in this 
language when you start trying to make them look like JavaScript, Ruby, etc. 
just to make them “stand out” when in reality all you’re doing is cluttering a 
once-simple idea.

tl;dr Don’t fix what ain’t broke.  Don’t complect what ain’t already simple.

I hope I’ve explained myself sufficiently well, because I don’t feel like I got 
my point across with those last 2 emails.  You have my email if you have 
anything you want to say to me personally.

~Robert Widmann

> On Dec 27, 2015, at 6:38 PM, Alexander Regueiro  wrote:
> 
> Then you clear know nothing of the history of computer science. I repeat, the 
> original syntax of the lambda calculus, to which you were referring, was 
> *not* designed for readability. Its purpose was entirely different. This is 
> only the start of the differences – there really isn’t anything to be gained 
> by comparing Swift with it – the differences in aim, nature, and context are 
> vast.
> 
> Now, you’re comparing a lambda expression to a let binding? That’s even more 
> nonsensical.
> 
> Bye.
> 
>> On 27 Dec 2015, at 23:30, Developer  wrote:
>> 
>> Now, now, that's no way to talk about a century's worth of computing 
>> research.
>> 
>> Since you have yet to respond to my original point, I'll expound:
>> 
>> I see Swift's choice of "in" in context of other programming languages that 
>> admit anonymous inner scopes with little fuss.  Those tend to come from the 
>> ML-family, which uses
>> 
>> // args in scope
>> let e = expr in body
>> 
>> Here, what is lacking is visibility of scope, but what is gained is 
>> composability.  Swift takes this a step further with
>> 
>> let e = { args in body }(expr)
>> 
>> Thus, coming from the C-side of things, you get nearly the same benefits as 
>> the former, but with the feel of a C-like language.  To change `in` or 
>> permute the ordering of binder, body, or delimiter detracts from Swift's 
>> position in either of these.
>> 
>> All the best,
>> 
>> ~Robert Widmann
>> 
>> 2015/12/27 18:07、Alexander Regueiro  のメッセージ:
>> 
>>> The lambda calculus is a mathematical tool. It’s not designed for 
>>> readability. Your point is invalid.
>>> 
 On 27 Dec 2015, at 23:03, Developer  wrote:
 
 With a proper λ, that's the point.  The lambda calculus doesn't focus on 
 the delimiter between the binder and the body because it isn't the 
 important part of an abstraction, the rest is.  I would argue a 
 programming language shouldn't either.  What is to be gained by having 
 more syntax around a construct all about anonymity?
 
 ~Robert Widmann
 
 2015/12/27 17:56、Alexander Regueiro  のメッセージ:
 
> It’s been agreed by almost everyone that “in” is at the very least a poor 
> delimiter. It’s barely noticeable.
> 
>> On 27 Dec 2015, at 22:54, Developer  wrote:
>> 
>> Hell, we have Unicode support, why not λ (U+03BB)?  Seriously though, 
>> for a C-like language I have to agree that Swift's approach is one of 
>> the best.  I can't think of a way of improving it that wouldn't 
>> immediately clash with the style and syntax of the language.  Sure you 
>> could change a few keywords here and there, but fundamentally 
>> 
>> { args in body } 
>> 
>> Strikes a balance between C-like basic blocks and Objective-C-like 
>> blocks.  When you start making more of this implicit or shifting it 
>> around, you have to necessarily start caring about things like 
>> whitespace and implicit scoping (I notice in the example you give, it is 
>> immediately less clear which identifiers are bound into what block). 
>> Things I don't 

Re: [swift-evolution] Lambda function syntax

[Developer via swift-evolution]

Oh my, no.  I don't intend Swift to become the λ calculus, I was merely making 
an analogy (and a joke, 3 replies ago).  In the same way that λ is the simplest 
set of rules embodying the powerful construct abstraction is, Swift's syntax 
for it is probably the simplest and best we can get given the style of other 
existing pieces of syntax.  Unfortunately, I think people see math and get a 
bit freaked out!

~Robert Widmann

2015/12/27 20:11、Wallacy <walla...@gmail.com> のメッセージ:

> 
> So how do you expect me to type "naturally" the character λ?
> 
> Not all keyboards are equal, are different languages around the world, with 
> different keyboard layouts. However in all I can type "in" but not this 
> symbol that can only reproduce by copying and pasting.
> 
> 
>> Em dom, 27 de dez de 2015 às 21:58, Developer via swift-evolution 
>> <swift-evolution@swift.org> escreveu:
>> Notation is not an arbitrary construct, and the choice of how to represent a 
>> λ-abstraction isn’t either.  When Church designed the calculus, he chose 
>> just 3 simple constructs: variables, abstractions, and applications, to be 
>> the entirety of the language.  Readability in the system is derived from 
>> simplicity of notation and concept, not from syntactic noise - far removed 
>> from this system through decades of investigation and simplification by 
>> other logicians and combinatorists.
>> 
>> I chose my examples from languages that I believe stay truest to the 
>> original vision of a λ - Swift included - because I believe they best inform 
>> my argument that the syntax needn’t change to fit a particular style because 
>> it is, by some definitions, unreadable.  In fact, I find it to be just as 
>> readable, if not more, than the other languages I mentioned precisely 
>> because the existing syntax blends in so nicely with the goal of the past 
>> and the syntax we have now.
>> 
>> I believe that in changing the ‘in’ keyword or the other ideas below amounts 
>> to little more than another permutation of syntax overtop an already good 
>> model.  If anything, you really start to lose the original intent of 
>> closures in this language when you start trying to make them look like 
>> JavaScript, Ruby, etc. just to make them “stand out” when in reality all 
>> you’re doing is cluttering a once-simple idea.
>> 
>> tl;dr Don’t fix what ain’t broke.  Don’t complect what ain’t already simple.
>> 
>> I hope I’ve explained myself sufficiently well, because I don’t feel like I 
>> got my point across with those last 2 emails.  You have my email if you have 
>> anything you want to say to me personally.
>> 
>> ~Robert Widmann
>> 
>> > On Dec 27, 2015, at 6:38 PM, Alexander Regueiro <alex...@gmail.com> wrote:
>> >
>> > Then you clear know nothing of the history of computer science. I repeat, 
>> > the original syntax of the lambda calculus, to which you were referring, 
>> > was *not* designed for readability. Its purpose was entirely different. 
>> > This is only the start of the differences – there really isn’t anything to 
>> > be gained by comparing Swift with it – the differences in aim, nature, and 
>> > context are vast.
>> >
>> > Now, you’re comparing a lambda expression to a let binding? That’s even 
>> > more nonsensical.
>> >
>> > Bye.
>> >
>> >> On 27 Dec 2015, at 23:30, Developer <devteam.cod...@gmail.com> wrote:
>> >>
>> >> Now, now, that's no way to talk about a century's worth of computing 
>> >> research.
>> >>
>> >> Since you have yet to respond to my original point, I'll expound:
>> >>
>> >> I see Swift's choice of "in" in context of other programming languages 
>> >> that admit anonymous inner scopes with little fuss.  Those tend to come 
>> >> from the ML-family, which uses
>> >>
>> >> // args in scope
>> >> let e = expr in body
>> >>
>> >> Here, what is lacking is visibility of scope, but what is gained is 
>> >> composability.  Swift takes this a step further with
>> >>
>> >> let e = { args in body }(expr)
>> >>
>> >> Thus, coming from the C-side of things, you get nearly the same benefits 
>> >> as the former, but with the feel of a C-like language.  To change `in` or 
>> >> permute the ordering of binder, body, or delimiter detracts from Swift's 
>> >> position in either of these.
>> >>
>> >> All the best,
>> >

Re: [swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

[Developer via swift-evolution]

+1.  Stream support is long overdue.

~Robert Widmann

2015/12/28 2:20、Kevin Ballard via swift-evolution  
のメッセージ:

> ## Introduction
> 
> Add a new property `cycle` to CollectionType that returns an infinite 
> SequenceType that yields the elements of the collection in a loop.
> 
> ## Motivation
> 
> It's sometimes useful to be able to have an infinite sequence. For example, 
> `CollectionOfOne(x).cycle` could be used to have an infinite sequence of a 
> single element (similar to Repeat but without a count). A common use for 
> infinite sequences is zipping with a finite sequence. As far as I'm aware, 
> the stdlib does not currently provide any way to create such an infinite 
> sequence.
> 
> ## Proposed solution
> 
> Extend CollectionType with a new property `cycle` that yields a type that 
> conforms to SequenceType. This sequence yields each element of the collection 
> in an infinite loop.
> 
> ## Detailed design
> 
> 2 new types would be added:
> 
> struct CycleSequence : LazySequenceType { ... }
> struct CycleGenerator : GeneratorType { ... }
> 
> CollectionType would be extended with a property:
> 
> extension CollectionType {
>public var cycle: CycleSequence { get }
> }
> 
> This is an extension of CollectionType instead of SequenceType because it 
> requires a multi-pass sequence (and SequenceType does not provide that 
> guarantee). The returned type conforms to SequenceType instead of 
> CollectionType because there is no possible `endIndex` that satisfies the 
> requirement of being reachable from `startIndex` by zero or more applications 
> of `successor()`.
> 
> Because the default eager versions of map and filter will execute forever on 
> an infinite sequence, CycleSequence conforms to LazySequenceType instead of 
> SequenceType in order to provide lazy versions of those functions. 
> Additionally, it will provide implementations of the eager versions that 
> simply trigger a fatalError(), as the alternative is an infinite loop that 
> consumes more and more memory.
> 
> ## Impact on existing code
> 
> None
> 
> -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