[swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

[Adrian Zubarev]

Ok fine your point is that we should not restrict redundancy in `Any<>`. Shall I still submit this to see what the core team thinks about it, even if it gets rejected?

-- 
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 18:08:44, Matthew Johnson (matthew at anandabits.com) schrieb:


On May 20, 2016, at 11:03 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:

I’m referring to this talk form the SE-0095 thread:

My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t break existing code.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

-DW

> On May 19, 2016, at 12:43 AM, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form.
> 
> Austin
> 
> 
>> On May 18, 2016, at 11:33 PM, Colin Barrett <colin at springsandstruts.com> wrote:
>> 
>> There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).
>> 
>> -Colin (via thumbs)
>> 
>>> On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng at gmail.com> wrote:
>>> 
>>> - 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.

We could allow everything. Personally I wouldn’t care much, because of best practice style. But if we will decide to restrict something after Swift 3 drops this will break code again, which we want to avoid, am I right?

If we wanted to do it it would probably be for a very good reason and we would probably be willing to accept the breakage.  Let’s not introduce arbitrary and somewhat complex restrictions just because “we can’t break code after Swift 3”.


-- 
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:40:03, Matthew Johnson (matthew at anandabits.com) schrieb:


On May 20, 2016, at 10:19 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:

I don't understand what you mean.  I definitely think your 'typealias ABC = Any<AB, C>' should be valid.
I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn’t be valid.

IMO the rules around banning nested any are unnecessary complexity.  The constructs have a well defined meaning.  The argument to ban them is purely around limiting allowable syntactic style.  People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case.  The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

Any rules that ban syntactic constructs which have a well defined meaning on purely stylistic grounds.  Those introduce unnecessary complexity for little, if any benefit.  As Tony points out, it is possible that such bans would have unintended consequences and ban useful constructs.  It is not worth the effort to try to ensure they don’t have unintended consequences.  

We rely on people to do sensible things stylistically all the time (Swift does not enforce code layout like some languages do).  I don’t see why `Any` should be different.


-- 
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew at anandabits.com) schrieb:

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
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/20160520/2de788b1/attachment.html>