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

[Xiaodi Wu]

On Sun, Dec 10, 2017 at 7:59 AM, Brent Royal-Gordon <brent at architechies.com>
wrote:

> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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 also think it should be an attribute.
>
> The last time I said this, I pointed out that this was a protocol which:
>
> 1. Has no formal members,
> 2. But imposes informal requirements enforced by the compiler,
> 3. Permits and uses arbitrary overloads, and
> 4. Cannot be usefully used in a generic context or as a type constraint,
>
> None of which are true of ordinary protocols. Since then, we have added:
>
> 5. Can only be conformed to in the main declaration.
>
> This is looking less like a protocol by the day. The square-peg grooves in
> the round hole are getting deeper and more splintery with every revision.
>

Synthesized conformances cannot be declared in extensions either. If you'd
like, you could consider that this protocol is one for which the compiler
synthesizes an infinite number of members.

I would like to see (4) addressed: a complete implementation should allow
me to call any member on a type T in a generic context where T :
DynamicMemberLookupProtocol, which I kind of assumed that this proposal
would eventually permit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171210/37680a2a/attachment.html>