> On 4 Aug 2016, at 13:00, Raphael Sebbe <[email protected]> wrote:
>
> Thank you Chris, James.
>
> I'm answering James feedback/questions below.
>
>> On Thu, Aug 4, 2016 at 1:57 AM James Froggatt <[email protected]> wrote:
>>
>> What are your thoughts on using tuples for this?
>>
>> typealias CGPoint4 = (CGPoint, CGPoint, CGPoint, CGPoint)
>>
>> struct Quad { var corners: CGPoint4 }
>>
>> var fixedLength = (point1, point2, point3, point4)
>> print(fixedLength.0)
>> print(fixedLength.4) //compiler error, not an element of the tuple
>>
>> With shorthand declaration syntax, this would have the benefits of a
>> fixed-length array with added compile-time safety. A previously suggested
>> syntax was along the lines of '(CGPoint * 4)'.
>>
>
> I investigated tuples a bit, it's close. The one thing I'd need is being able
> to index the values using a variable. The tuple.i notation apparently doesn't
> work (or I did not try hard enough). Also, for low-level things that will be
> mapped to GPU memory, precise/predictable/settable alignment is needed.
Good point. A similar mechanism might be possible eventually for tuples, but
right now this isn't possible.
>>> 4. Reference/pointer to structs: accessing & modifying structs deep into
>>> the model currently requires fully qualified path to the struct instance.
>>> Fully qualifying an inner struct in your data model can be very tedious,
>>> depending on model complexity.
>>>
>>> For instance, with scoped access solutions made with Swift 3, you need to
>>> cascade blocks if you need to access multiple inner structs, which doesn't
>>> scale well as it creates code pyramids:
>>>
>>> scopedAccess(&varA) {
>>> scopedAccess(&varB) {
>>> // modify varA & varB
>>> }
>>> }
>>>
>>> It's easily done in C/C++ using pointers/references. To make that better,
>>> we'd need some kind of language support IMO.
>>
>> Could this be generalised, maybe with a reference-semantic ‘property
>> accessor’?
>>
>> Example:
>>
>> let get: () -> Bool = #get(controller.view.isVisible)
>> print(get())
>>
>> let set: (Bool) -> () = #set(controller.view.isVisible)
>> set(true)
>>
>> let accessor: Lens<Bool> = #lens(controller.view.isVisible)
>> print(accessor.value)
>> accessor.value = true
>>
>> This would have the added bonus of also tracking the reassignment of
>> reference-type properties - in this example, if 'view' is reassigned, the
>> referenced value is updated.
>
> Sounds good, I'm not aware of this syntax. Will investigate, thanks.
Sorry, I was suggesting a *possible* syntax. No such syntax currently exists,
though the functionality can be imitated with closures:
let get: () -> Bool = {controller.view.isVisible}
print(get())
let set: (Bool) -> () = {controller.view.isVisible = $0}
set(true)
struct Lens<T> {
var get: () -> T
var set: (T) -> ()
var value: T { get { return get() } set { set(newValue) } }
}
let accessor: Lens<Bool> = Lens(get: {controller.view.isVisible}, set:
{controller.view.visible = $0})
print(accessor.value)
accessor.value = true
It's a bit more verbose when creating the get-set accessor, and may not perform
optimally, but it's actually pretty functional.
>
>>
>>> 5. Memory / pointer access, including casting. It's too verbose currently
>>> IMO when compared to C. Should be better supported for a language that is
>>> also targeting low-level (network, disk storage). A syntax that is both
>>> fast (like C) and safe would be great.
>>
>> Not familiar with low-level programming in Swift, but have you considered
>> creating domain-specific operators?
>> For example, I imagine something like 'UnsafeMutablePointer(v)' could be
>> reduced to '*v'.
>>
>
> Do you mean operator is available only within a limited scope? That would be
> interesting, because I don't want to pollute global scope with such
> all-purpose operator. Sounds that I need to investigate that as well.
If you have a specific module which performs this sort of operation a lot, you
can just declare the operator as internal. If it's needed in several, making a
separate module for the operators could be preferable.
>>
>>> 7. I'm also fan of async/await kind of stuff, asynchronous flows, etc., but
>>> this has already been mentioned -> cool!
>>
>> I would like to see some ideas in this area.
>> async/await never really clicked for me until I realised it's just syntactic
>> sugar - 'await' actually ends the function, and everything below is an
>> implicit callback. Personally I feel like Swift's trailing closure syntax
>> makes callbacks lightweight enough that this isn't so much of an issue.
>> Something focusing more on the memory-management and thread-safety aspects
>> of asynchronous code does seem useful in the context of Swift.
>>>
> Sure thread-safety, atomicity features would be really nice & useful.
>
> The one problem I have with closure syntax (trailing or not, I like trailing
> too), is that when you chain a few of them, which is pretty frequent is async
> programming, you end up with a closure pyramid. It doesn't scale well beyond
> 2 or 3 levels.
Makes sense._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
