> On Dec 28, 2015, at 6:12 PM, Goffredo Marocchi <pana...@gmail.com> wrote:
>
> One could say that is extremely petty to redefine very commonly accepted
> words (private when we mean file restricted, internal when we mean
> essentially package when there are already pretty well understood meaning
> from languages which quite frankly Swift will not kill now or 5 years from
> now... Java and C++ will keep dominating the landscape with bigger threats
> coming from JavaScript, ruby, etc... embracing and extending seems like a
> more successful strategy than taking a defined word and changing its meaning).
>
> Also, the current do fails the Yoda test... do or do not, no try ;).
>
> I would suggest replacing repeat with do and the current do with something
> like throwing which the compiler could actually use to generate errors of we
> are creating a throwing block without any method that could actually throw
> and I would not touch the current try keyword to minimise changes.
Maybe “throws” instead of “throwing" as in:
throws {
let z = try f(x, y)
} catch … {
}
>
> Sent from my iPhone
>
>> On 28 Dec 2015, at 22:15, Amir Michail via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>>>> On Dec 28, 2015, at 1:25 AM, Brent Royal-Gordon <br...@architechies.com>
>>>> 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.
>>>
>>> Do you also propose no longer marking calls to throwing functions with
>>> `try`?
>>
>> Maybe put “throws” after such function calls?
>>
>> try {
>> let z = f(x,y) throws
>> } catch … {
>> }
>>
>> You could also have “throws?” and “throws!” following the function call.
>>
>>> Have you read the "Error-Handling Rationale" document in the Swift
>>> repository? If not, please do:
>>> <https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst>
>>> If so, please explain why you disagree with it.
>>>
>>> --
>>> 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
