[swift-evolution] Proposal: Add generator functions to the language

[Drew Crawford]

One difference is the memory usage:

func helloGenerator() -> LazyCollection<[String]> {
    return [
        1GBAllocation(),
        1GBAllocation()
    ].lazy
}

vs

func helloGenerator() -> SequenceType {
	yield 1GBAllocation()
	//allocation released
	yield 1GBAllocation()
}


> On Dec 11, 2015, at 7:38 PM, Kametrixom Tikara via swift-evolution <swift-evolution at swift.org> wrote:
> 
> What exactly is the difference to just returning a sequence?
> 
> func helloGenerator(name : String?) -> [String] {
>     return [
>         "Hello",
>         name ?? "World"
>     ]
> }
> 
> for str in helloGenerator("David") {
>     print(str)
> }
> 
> And if you want if lazy:
> 
> func helloGenerator(name : String?) -> LazyCollection<[String]> {
>     return [
>         "Hello",
>         name ?? "World"
>     ].lazy
> }
> 
> Seems like exactly the same, except it doesn’t need two new keywords nor revamping of SequenceType/GeneratorType
> 
>> On 12 Dec 2015, at 01:21, David Waite via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Looking for feedback on crafting a proposal adding generator functions to Swift. I understand this will likely be a very involved proposal at the language level, although I actually don’t know the complexity of the change within the Swift compiler itself.
>> 
>> This would be a function which returns multiple values, which is converted by the compiler to a function returning a SequenceType
>> 
>> A very basic syntax would be to add generator as a modifier to func, and likely involve a new keyword ‘yield’ to differentiate from the flow control behavior of ‘return’.
>> 
>> So for example:
>> 
>> generator func helloGenerator(name:String?) -> String {
>>     yield “Hello”
>>     yield name ?? “World”
>> }
>> 
>> Would have the following expected usage:
>> 
>> for str in helloGenerator(“David") {
>>    print str
>> // prints:
>> //    Hello
>> //    David
>> }
>> 
>> And for those unfamiliar to these sorts of simple cases, would have equivalent behavior to the following code:
>> 
>>  45> func helloGenerator(name:String?) -> HelloGenerator { 
>>  46.   return HelloGenerator(name) 
>>  47. } 
>>  48.  
>>  49. struct HelloGenerator : GeneratorType, SequenceType { 
>>  50.    var position:Int = 0 
>>  51.    let name:String? 
>>  52.  
>>  53.    private init(_ name:String?) { 
>>  54.       self.name = name 
>>  55.    } 
>>  56.     
>>  57.    func generator() -> HelloGenerator {
>>  58.        return self 
>>  59.    } 
>>  60.      
>>  61.    mutating func next() -> String? { 
>>  62.       switch position { 
>>  63.       case 0: 
>>  64.           position = 1 
>>  65.           return "Hello" 
>>  66.       case 1: 
>>  67.           position = 2 
>>  68.           return name ?? "World" 
>>  69.       default: 
>>  70.           return nil 
>>  71.       } 
>>  72.    } 
>>  73. } 
>> 
>> This syntax has at a bare minimum issues with generator closures and for a terse syntax for yielding over another sequence type within a generator function vs. using a loop. (possibly “yield in sequenceName”)
>> 
>> The interaction with the error system might involve disallowing throws from generator functions, or having the Element type be a Result<T> rather than T, as the GeneratorType next() method is not declared as throwing.
>> 
>> This could pair well to make for-in loops more comprehensive, especially if C-style for loops are eliminated.
>> 
>> This would possibly be a first step toward a coroutine-based concurrency system, although I am not proposing that sort of usage or scope here. The goal would be to emit an object compatible with SequenceType
>> 
>> -David Waite (DW)
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/fb0e0b15/attachment.html>