[swift-evolution] [Review] SE-0030 Property Behaviors

Jean-Daniel Dupas mailing at xenonium.com
Sat Feb 13 17:27:42 CST 2016


> Le 13 févr. 2016 à 21:23, Jérôme Duquennoy via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Hi everyone,
> 
> First, I'm sorry, I have very few spare time currently, so I will only make a quick contribution to that topic.
> 
> I love this discussion, it is really an interesting feature, that could be very useful in some parts of my existing code.
> I would like to raise a concern about the syntax : as Chris said, the square brackets are already heavily used for collections and subscript.
> Given that swift might be used as a scripting language too, it will probably be written using a "simple" text editor like sublimeText, textMate, vi  or equivalent ones in many cases. Those editor does not use sourceKit or LLVM to apply syntax coloring. The analysis is much simpler, often based on regexp.
> I think that re-using the square brackets here would make it hard for them to provide accurate coloring, thus lowering the ease of use and reducing the attractiveness of swift as a scripting language.

I don’t think it is more complex to distinguish between subscript and behavior access (behavior as a leading dot), than between attribute or « macro » and behavior access (if we choose to use @ or # for behavior).

That said, I’m not found either of the bracket proposal, but don’t have anything to propose to replace it though.

> This feature is a +1 for me, but I would prefer an alternative syntax for it, like the @ prefix proposed in the review, or the # prefix proposed by Chris.
> 
> Jerome
> 
>> Le 11 févr. 2016 à 07:13, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> I think that something like this is a bit better aesthetically, since the [] delimiters are heavily array/collection/subscript-centric (which is a good thing).  OTOH, this would be giving users access to the “#” namespace, which means that future conflicts would have to be resolved with backticks - e.g. if they wanted a “line” behavior, they’d have to use "var #`line` foo = 1738”. I guess the fact that we already have a solution to the imagined problem means that this isn’t a big concern in practice.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160214/f9cb6b25/attachment.html>


More information about the swift-evolution mailing list