One comment Inline
> On 20 Jul 2016, at 07:58, Charlie Monroe via swift-evolution
> wrote:
>
> I'd personally leave it as is, but am kind of indifferent on the matter.
>
> The subscript is a hybrid between var and func and with the arguments, it
> always felt more of a function to me, without
I have mixed feelings about moving from standard parameter list syntax. I'd
like to see the discussion, but it would need its own proposal. It might still
be possible to get this in before the deadline, if you or anyone is up to it.
Begin Message
Group: gmane.comp.la
Marking the return value is certainly a direction we could go, but my reasoning
in this proposal was that ‘-> inout’ is semantically equivalent to the colon,
as it exists today for computed properties.
I think this the result of this proposal will set the precedent for if/when we
do add this fea
Yeah, you might be right about the style, though to be honest I'm not entirely
sure what the rule is for this. My reasoning was that if a space before a colon
is justified anywhere, it should be acceptable here.
I'm not sure whether it's possible to update the proposal once submitted.
Realised
> Brent Royal-Gordon: If, as seems likely for lens support, we eventually
> supported inout functions:
>
> func foo(x: Int) -> inout String {
> get { return myStr }
> set { myStr = newValue }
> }
>
> Would you feel differently about having `:` on subscript
I think there’s some value to point out these counterparts even when we are
trying to do something new. Specifically, how much would we have lost, if we
didn’t accept the proposal? By looking at these examples, one might conclude
“not much”.
Also, it’s not the main reason I’m against this chang
I don't disagree with discussing other languages. I'm just pointing out that
C++ doesn't have a notion of computed properties, so subscript couldn't pretend
to be a computed property even if it'd like! Python does have a similar
construct, but it's computed properties *also* look like functions
It's part of the review template :)
Daniel Duan
Sent from my iPhone
> On Jul 20, 2016, at 7:23 PM, Jaden Geller wrote:
>
>> Python's __getitem__() method, C++'s [] operator are some analogous
>> examples. Non -of them pretend not to be a function. The users of these
>> features appear to be s
> Python's __getitem__() method, C++'s [] operator are some analogous examples.
> Non -of them pretend not to be a function. The users of these features appear
> to be satisfied by the decision.
This seems irrelevant since Swift already has computed properties which pretend
not to be a function
* What is your evaluation of the proposal?
-1.
To me, subscripts have always seen more functions than properties for the fact
that they can take arbitrary number of arguments. If we were to "clean up" its
syntax, I'd rather align it with functions. Something along the lines of
subscribe(get
Sent from my iPad
On Jul 20, 2016, at 8:47 PM, Brent Royal-Gordon via swift-evolution
wrote:
>> On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution
>> wrote:
>>
>> However, the current notation of -> Type being used to declare an input
>> parameter to set {} just strikes me as
> On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution
> wrote:
>
> However, the current notation of -> Type being used to declare an input
> parameter to set {} just strikes me as weird and wrong. The symbol -> means
> “returns a” or “yields”. Since we’re declaring a type that might
> * What is your evaluation of the proposal?
I would be in favor if we make the change to square brackets that everyone is
talking about. Otherwise I am indifferent.
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
I do feel that the current setter behavi
+1
I prefer the current syntax from a subjective and readability perspective.
However, the current notation of -> Type being used to declare an input
parameter to set {} just strikes me as weird and wrong. The symbol -> means
“returns a” or “yields”. Since we’re declaring a type that might be e
> On Jul 20, 2016, at 10:36 AM, Leonardo Pessoa wrote:
>
> I like this syntax better. But do you guys think we could remove this
> "subscript" prefix?
I like the subscripts to be explicit.
> Could we actually bring subscripts closer to
> computed properties by doing something like "var self[ex
I like this syntax better. But do you guys think we could remove this
"subscript" prefix? Could we actually bring subscripts closer to
computed properties by doing something like "var self[externaName
internalName : ParamType] : ElemenType"? That could also support the
idea of creating named subscr
I’ll concur with Jose:
Either replace parens with square brackets so the declaration of a
subscript matches its point of use (in which case a colon would be
acceptable) or else leave it as it is.
I am (-1) on the proposal as written, (+1) on square brackets for
subscripts (with either colon or ar
> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution
> wrote:
>
> +1 to clean up the syntax of subscripts. They acts as properties, not
> methods, so it is natural to express them with `:` and not with `->`.
>
> Actually, I'd prefer additional change to use [] instead of () in declar
I’m +0.5 on this. I think it’s very natural to think of subscript as a
parameterized property. I've felt like I’m doing mental gymnastics to reconcile
the signature of the setter, and I think replacing `->` with `:` might actually
make this easier to reason about.
I’m not sure why the style in
-1 from me. Getter subscipts are closer to functions, where name is
`subscript`.
Of course, they are called with brackets, but they are still a kind of
functions, and when we assign them to function variables, they get type
that matches their declaration.
2016-07-20 8:50 GMT+03:00 Chris Lattner vi
Anton, I think where people find the current notation problematic is with
_setters_, not getters.
On Wed, Jul 20, 2016 at 11:58 AM, Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:
> -1 from me. Getter subscipts are closer to functions, where name is
> `subscript`.
> Of course
Regards
LM
(From mobile)
On Jul 20, 2016, at 2:16 PM, Brent Royal-Gordon via swift-evolution
wrote:
>> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution
>> wrote:
>>
>>* What is your evaluation of the proposal?
>
> I think the colon has too little visual weight for this
On 20 July 2016 at 02:50, Chris Lattner via swift-evolution
wrote:
> Hello Swift community,
>
> The review of "SE-0122: Use colons for subscript declarations " begins now
> and runs through July 24. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/maste
On 20.07.2016 9:12, Dmitri Gribenko via swift-evolution wrote:
On Tue, Jul 19, 2016 at 10:50 PM, Chris Lattner via swift-evolution
wrote:
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and
runs through July 24. The proposal is available here:
+1 to clean up the syntax of subscripts. They acts as properties, not
methods, so it is natural to express them with `:` and not with `->`.
Actually, I'd prefer additional change to use [] instead of () in
declaration like:
subscript[externalName internalName: ParamType] : ElementType {
g
> On Jul 20, 2016, at 5:16 AM, Brent Royal-Gordon
> wrote:
>
> subscript(id widgetID: WidgetUUID): Widget { … }
Plus, as a minor issue, certain chat clients which shall remain nameless will
convert `):` to a graphical smiley. That will make some programmers frown.
--
Brent Royal-Gordon
> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution
> wrote:
>
> * What is your evaluation of the proposal?
I think the colon has too little visual weight for this role. In a property
declaration, the colon sits to the right of an identifier:
var widgetID: WidgetUU
> On 20 Jul 2016, at 06:50, Chris Lattner via swift-evolution
> wrote:
>
> * What is your evaluation of the proposal?
I'm leaning towards in favour, but very marginally as to be frank I'm not that
bothered either way. The subscript is a definite hybrid of property and
function, but the
> What is your evaluation of the proposal?
I’m afraid I’m against this proposal, since IMO colons are no better in this
case than the arrow syntax.
> Is the problem being addressed significant enough to warrant a change to
> Swift?
I understand that the current syntax isn’t as clear as it pos
> On 20 Jul 2016, Chris Lattner wrote:
>
> The review of "SE-0122: Use colons for subscript declarations " begins now
> and runs through July 24. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declar
Sent from my iPhone
> On 20 Jul 2016, at 06:50, Chris Lattner via swift-evolution
> wrote:
>
> Hello Swift community,
>
> The review of "SE-0122: Use colons for subscript declarations " begins now
> and runs through July 24. The proposal is available here:
>
>
> https://github.com/appl
> What is your evaluation of the proposal?
I'm not in favor of it because I see no tangible benefit, and it feels like we
don't need changes that break source for the sake of breaking source already. I
don't think that it's worth the effort.
> Is the problem being addressed significant enough t
On Tue, Jul 19, 2016 at 10:50 PM, Chris Lattner via swift-evolution
wrote:
> Hello Swift community,
>
> The review of "SE-0122: Use colons for subscript declarations " begins now
> and runs through July 24. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/bl
I'd personally leave it as is, but am kind of indifferent on the matter.
The subscript is a hybrid between var and func and with the arguments, it
always felt more of a function to me, without them, it felt more like a var to
me.
The logical thing might be to have double-syntax:
subscript: Int
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and
runs through July 24. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md
Reviews are an i
35 matches
Mail list logo
