I definitely see where John is coming from, but my intuition (which I have to agree is of arguable worth) is telling me that it’s a good direction to explore. I believe that the current system is broken, even if the degree of this is not significant, and doesn’t affect most uses. As the language matures, and the use of error-throwing with a more functional style of programming becomes more prevalent, I think that some form of advance in the matching system will have to be made.
Here’s my perspective on this: (Disclaimer: I’m having a bit of trouble getting my head around the compiler, and exactly how “rethrows" and type unification work.) * I’m very fond of the availability of rethrows as a function declaration annotation, it’s very clear in its requirements and in its guarantees. By allowing it to be a type annotation, these same contracts can be used by the readers of the code, and by the compiler. (For example, a function is throwing iff there is a reachable, uncaught, throwing expression; a function is rethrowing iff it is not throwing and there is a reachable, uncaught, call to a function, taken as input, that is marked as throwing. This may or may not be useful to the compiler, but it would definitely help me when dealing with throwing code.) * Dmitri’s suggestion of making the compiler advanced enough to have the rethrows generated automatically doesn’t seem to be any less complicated than requiring the programmer to add it to the function type by hand. I’m also not entirely sure how it would work in a context where you declare that a function with rethrowing semantics is expected. Maybe I just missed the point of the comment entirely. — Sasha P.S. Is there documentation somewhere of the rules by which types are unified today, and of the way that "rethrows" is currently handled, or should I just keep working at reading the code? > On 22 Dec 2015, at 20:41, John McCall <[email protected]> wrote: > >> On Dec 21, 2015, at 6:09 PM, Jordan Rose <[email protected] >> <mailto:[email protected]>> wrote: >> John, IIRC you had some reason why this wasn't a great idea, but I can't >> remember it. It seems useful to me too, if not something that comes up too >> often. > > I don’t remember off-hand. I think it’s theoretically supportable, but it > adds extra complexity to the type system that I wanted to avoid if possible. > > John. > >> >> Jordan >> >>> On Dec 20, 2015, at 2:46 , Alexandre Lopoukhine via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hi Dmitri, >>> >>> This is a better example than any that I have come up with so far as to why >>> “rethrows” should be a part of the signature. You shouldn’t have to use >>> “try!” to apply a non-throwing function, like {print($0)} to “forEach”. >>> >>> — Sasha >>> >>> >>>> On 20 Dec 2015, at 13:37, Dmitri Gribenko <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi Alexandre, >>>> >>>> I think for this use case we don't actually need 'rethrows' to become >>>> a part of the closure type, we just need the compiler to allow and >>>> "instantiate" it in more places. >>>> >>>> The case where we would need 'rethrows' to become a first class part >>>> of the type system is if we wanted 'rethrows' to be a part of the >>>> signature of the closure itself, for example: >>>> >>>> (swift) let forEach = [ 10, 20, 30 ].forEach >>>> // forEach : (@noescape (Int) throws -> Void) throws -> () = (Function) >>>> >>>> Here, a more precise type would be (@noescape (Int) throws -> Void) >>>> rethrows -> Void. >>>> >>>> Dmitri >>>> >>>> -- >>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if >>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <[email protected] >>>> <mailto:[email protected]>>*/ >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
