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

[Steven Brunwasser via swift-evolution]

> On Dec 10, 2017, at 13:01, Chris Lattner via swift-evolution 
>  wrote:
> 
>>> On Dec 10, 2017, at 6:00 AM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser  
 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.
> 
> Hi Brent,
> 
> This approach definitely could work.  I added it to the alternatives section 
> with a breakdown of why I don’t think it’s the right direction:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#make-this-be-a-attribute-on-a-type-instead-of-a-protocol-conformance

I think the protocol vs attribute debate is more about what it means to be an 
attribute. I personally see attributes as eventually becoming a more extensible 
meta-programming tool, but that might not be the community’s consensus.

Assuming that attributes are for meta-programming, this would make more sense 
as an attribute, since its a tool for dynamically resolving undefined symbols 
at compile-time.

- Steve___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Steven Brunwasser via swift-evolution]

Just wanted to give my 2¢

¢
I don’t like empty protocols—they feel like an abuse of the feature. 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 
>  wrote:
> 
>> On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution 
>>  wrote:
>> See below.
>> 
>>> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution 
>>>  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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution