[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Xiaodi Wu]

On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser <sbrunwasser at gmail.com>
wrote:

> Just wanted to give my 2¢
>
> ¢
> I don’t like empty protocols—they feel like an abuse of the feature.
>

As has been discussed here before, protocols aren’t about bags of syntax
but rather about semantics. Empty protocols are explicitly a demonstration
of this settled principle and are very much consistent with the direction
of Swift.

I think attributes are the right way to go, since this proposal is about
> enabling syntactic sugar for types which can’t yet be described in the
> language as-is. This prevents retroactive conformance on preexisting types,
> which some have raised as a concern.
>
> ¢
> I think the discussion about whether or not implementations should throw,
> return optional, or be implicitly unwrapped is a larger discussion on its
> own, and should probably be a separate proposal to steer the language
> towards a more well defined convention. That being said, I’m of the opinion
> that they should always return an implicitly unwrapped value. The precedent
> is already in the language, it allows for cleaner syntax while also
> explicitly stating “hey, just so you know, I might not work, so be careful,
> ok?”, and callers can choose to be more cautious by explicitly using the ?
> operator.
>
> That is all,
> - Steve
>
> On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> See below.
>>
>> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Apologies, I may have misunderstood you. What I wanted to say is that I
>> see no problem allowing "dangerous" stuff that may be abused.
>>
>>
>> You see no problem with danger and abuse?
>>
>> I guess we have differing philosophies...
>>
>> https://developer.apple.com/swift/ states:
>>
>> “Swift eliminates entire classes of unsafe code.”
>>
>> Lets keep it that way.
>>
>> I’m all for this proposal if it can be tweaked to where any of the
>> dangerous invocations contain the word, “Unsafe”, or equivalent.
>>
>
> Again, in Swift, “safety” means something very specific. Trapping at
> runtime is safe; in fact, trapping at runtime is *precisely the means by
> which safety is achieved* in the case of integer overflow and array
> indexing. This proposal introduces nothing that is unsafe.
>
> ~Jon
>>
>>
>> _______________________________________________
>> 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/20171209/b17b3a30/attachment.html>