I have similar concerns as David. I do like the idea but I see it becoming
a problem in not a typical usage as David outlined. You likely would never
want to use this in any public API or possibly any function signature for
that matter (again given the limits implied by the short hand). I see it
being useful in a given scope of code for the purpose of readability and
even safety. It is when it starts to escape that scope it become less
useful and possibly unsafe.
···
On Mon, Feb 22, 2016 at 9:12 AM David Waite via swift-evolution < swift-evolution@swift.org> wrote:
Having this work similar to other anonymous types would be an extension to
the proposal.Other anonymous types can be considered equivalent by their definitions,
e.g. (x:Int, y:Int) taken as input from one function can be passed to
another.E.g. your adjustTemperature function wanted to call a
checkSafety(device:DeviceType, [low | medium | high]:temperature) -> Bool
function - could it?what about if adjustTemperature took [low | medium | high | extreme]?
what about adjustTemperature having an internal var lastAdjustment:[low |
medium | high] - would that work?My concern is that there could many reasons to need to switch from
shorthand/anonymous syntax to a full enum, and that switch will have the
same fragility as changing a function from accepting a tuple to accepting a
struct. If passing to another function or assigning to a variable would
require a switch to a properly qualified enum, the feature seems not worth
its character savings.And I’m already unsure it is worth its existing character savings,
especially once you start documenting the meaning of low / medium / high
for other developers, and especially if you now have to do so for multiple
functions rather than a single enum declaration.-DW
On Feb 22, 2016, at 9:46 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote:
I'm not sure wether I want to see that feature added, but I think there is
a "structural" argument for it:
We have anonymous functions (closures) and a (restricted) form of
anonymous structs (tuples), so it would be consequent to have a anonymous
variant for each fundamental entity in the language.
I guess it is to late to establish a unified syntax for all of those,
though…I like the symmetry with the other anonymous types. This provides a highly
focused tweak to Swift, with limited impact, and a measurable benefit to
developers. (AKA the "Rule of Lattner")Further, the values cannot be assigned to variables or passed as arguments
as they have no "type". I suspect it won't be hard to restrict them for
being used with `Any` argument, limiting their use to flags and switch
cases. If I'm conceptualizing this correctly, the benefits are clear and
the consequences are small.-- Erica
On Feb 21, 2016, at 11:52 PM, Yong hee Lee via swift-evolution < > swift-evolution@swift.org> wrote:
please check the link below.
_______________________________________________
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