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

[L. Mihalkovic]

Regards
(From mobile)

> On May 20, 2016, at 5:39 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> 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.  
> 

If i am not mistaken, linters exist so that these rules can be created an enforced without having to introduce special cases in compilers.

> 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/aeadf8ab/attachment.html>