Ah thanks! I forgot to select the Reply All option. My first email:
>> Maybe you can check it out: >> >> https://github.com/JustinJiaDev/SwiftShell >> >> I prefer to write ls(.all, .longFormat) instead of ls([.all, .longFormat]). >> The former one looks a lot nicer. And it is much easier to type. This is >> important if I want to use it as a shell. Dennis's reply: > Hey Justin, you didn’t include the list, if you want to keep your mail > private: perfect, if not: now you know it :) > > Regarding your example: > > I think that’s a pretty good use case for an OptionSetType (which, > unfortunately for you, leads to the same syntax you dislike [without the dot > in front of the identifier]). > And remember that you can still overload the functions (having different > numbers of arguments) :) > > - Dennis I didn't realize that I can use OptionalSetType. Thanks for pointing it out! But I chose to use enum is because of the auto completion. I can see the list of options after I enter the leading dot. It's a experimental project. But my point is: Swift is very safe and efficient, but at the same time it is also very flexible. Removing this feature will harm its flexibility. I agree that we should remove the splat behavior, c style for loop and ++ -- operators, because sometimes they will confuse people. e.g. array[index++] = x; array[++index] = x; However, variadic functions are really easy to understand. For example: sum(x) average(x) NSLog("%d", x) NSString.stringWithFormat("%d", x) Justin > On Apr 18, 2016, at 2:13 PM, Dennis Weissmann <[email protected]> > wrote: > > Hey Justin, you didn’t include the list, if you want to keep your mail > private: perfect, if not: now you know it :) > > Regarding your example: > > I think that’s a pretty good use case for an OptionSetType (which, > unfortunately for you, leads to the same syntax you dislike [without the dot > in front of the identifier]). > And remember that you can still overload the functions (having different > numbers of arguments) :) > > - Dennis > >> On Apr 18, 2016, at 11:03 PM, Justin Jia <[email protected]> >> wrote: >> >> Maybe you can check it out: >> >> https://github.com/JustinJiaDev/SwiftShell >> >> I prefer to write ls(.all, .longFormat) instead of ls([.all, .longFormat]). >> The former one looks a lot nicer. And it is much easier to type. This is >> important if I want to use it as a shell. >> >> Justin >> >>> On Apr 18, 2016, at 5:55 AM, Dennis Weissmann <[email protected]> >>> wrote: >>> >>> Hm, sorry but I’m still not convinced :( >>> >>> I still find it confusing and I think if it wasn’t in Swift already, it >>> would not be added. Maybe someone can come up with a strong reason why it >>> should be added if it weren’t there. >>> >>> - Dennis >>> >>>>> On Apr 18, 2016, at 10:10 AM, Gwendal Roué <[email protected]> wrote: >>>>> >>>>> >>>>> Le 18 avr. 2016 à 10:02, Dennis Weissmann <[email protected]> a >>>>> écrit : >>>>> >>>>> That’s IMO already a problematic case: >>>>> >>>>>> DatabaseTable.select(id, name).order(name, id) // What’s the >>>>>> problem? >>>>>> // vs. >>>>>> DatabaseTable.select([id, name]).order([name, id]) // OK, of >>>>>> course... But some people will find it a litle short >>>>> >>>>> The problem is that you can’t tell by looking at the call site whether >>>>> `select` takes an id and a name as parameter (the function being declared >>>>> as `func select(id: String, _ name: String)` or a vararg `func >>>>> select(string: String…)`. >>>>> Both call sites look like this: >>>>> >>>>>> select(id, name) >>>>> >>>>> I think it would make the language clearer and more consistent if varargs >>>>> were removed. >>>> >>>> Sorry my example wasn’t clear enough, and that’s why you couldn’t tell by >>>> looking at the call site what was happening. You were missing context. >>>> "id" and "name" are not values, they’re database columns. It’s more >>>> something along: >>>> >>>> DatabaseTable { >>>> func select(columns: Column…) { … } >>>> } >>>> >>>> people.select(idColumn, nameColumn) >>>> furniture.select(nameColumn, widthColumn, heightColumn, depthColumn, >>>> priceColumn) >>>> >>>> (Sometimes examples are too complex, and don't serve well their purpose - >>>> my mistake) >>>> >>>> Maybe you’ll follow the counter argument now. Which is "of course a >>>> variadic function can always be turned into a function that takes an >>>> array, what a surprise, but this is not always the good thing to do." >>>> >>>> Regards, >>>> Gwendal Roué >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
