This: https://twitter.com/slava_pestov/status/874394132340289536
seems to suggest that the current Swift 4 behavior will not change much in
this domain.
On Tue, Jun 13, 2017 at 1:11 AM, Vladimir.S <sva...@gmail.com> wrote:
> On 12.06.2017 23:17, Jens Persson via swift-evolution wrote:
>
>> I think this proposal would be complicating rather than simplifying the
>> type system, it would be adding a special rule.
>> And it is not a step towards resolving the many parentheses-related
>> inconsistencies that still remain.
>>
>> Here is an example of one such remaining inconsistency, it's still in
>> (latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2)
>> and 4:
>> func foo() -> Void {}
>> func foo(_: Void) -> Void {} // This is OK
>> func bar(fn: () -> Void) {}
>> func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.
>>
>> I think the least surprising behavior here would be no error, rather than
>> two.
>> The current behavior with one error is very surprising.
>>
>
> As I understand, currently in Swift 4 there are a number of bugs related
> to function types, so I believe it is incorrect to make conclusions based
> on current behavior of Swift 4 code. I've asked John McCall in this thread
> about *planned* behavior of some Swift 4 release code related to function
> types, let's see what will be the reply.
>
> (I'd suggest to create a bug on bugs.swift.org for this particular issue
> - probably this will help to improve Swift 4 compiler)
>
>
>>
>> On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <
>> jeremie.gira...@gmail.com
>> <mailto:jeremie.gira...@gmail.com>> wrote:
>>
>> Exactly, that means that your implementation of the tuple
>> splatting operator
>> is out of the type system.
>> Can you expose it’s signature ?
>>
>> If you want the operator to be “compiler-magic” it’s possible.
>>
>> Yes, it requires compiler support.
>>
>> This proposal is an alternate solution.
>>
>> My point is that updating Void according to this proposal would
>> - preserve the type system in a better way
>> - have better source compatibility (in time for swift 4
>> release, were we
>> probably won’t see tuple splatting)
>> - also keep the elegant original syntax of swift instead of
>> stacking
>> parenthesis
>>
>> The impact for code writers would be minimized on time for swift
>> 4 release
>>
>> As for return values: this proposition does not intend to change
>> the how
>> return value of Void functions works.
>>
>> —
>> very short reply expected - vsre.info <http://vsre.info>
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com
>> <mailto:xiaodi...@gmail.com>) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault<
>>> jeremie.gira...@gmail.com
>>> <mailto:jeremie.gira...@gmail.com>>wrote:
>>>
>>> @xiaodi
>>> I disagree on many points, for example what is the type of x
>>> when we
>>> type `let x = *Void` ?
>>>
>>>
>>> That would not be a legal statement. Exploding a tuple is an
>>> operation that
>>> only makes sense inside an argument list. Likewise `let x =
>>> &Void` will not
>>> compile.
>>>
>>> This is the essence of the problem and this proposition
>>> wants to solve
>>> this.
>>>
>>> The regression is due to both reason combined : typealias
>>> Void = () AND
>>> SE-0110
>>>
>>> My proposition is to change the meaning of Void from () to
>>> “something
>>> else” that is type-compatible with SE-0110 (and splatting in
>>> the future).
>>>
>>>
>>> I'm not sure I understand your motivation. Void is just a
>>> typealias. If
>>> tomorrow Void meant something else, all functions must still
>>> return (), and
>>> there is still no implicit tuple splatting.
>>>
>>
>>
>>
>>> If you want an example of the changes needed to migrate to
>>> swift4, just
>>> look at the 42 files of handling parenthesis PR of RxSwift
>>> needed for
>>> swift4 upgrade : https://github.com/ReactiveX/R
>>> xSwift/pull/1282/files
>>> <https://github.com/ReactiveX/RxSwift/pull/1282/files>
>>>
>>>
>>> Indeed, that's the result of SE-0110; these parentheses are
>>> needed because
>>> there is no implicit tuple splatting. They would be required
>>> even if `Void`
>>> did not exist in the language at all.
>>>
>>>
>>> —
>>> very short reply expected -vsre.info <http://vsre.info>
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com
>>> <mailto:xiaodi...@gmail.com>) wrote:
>>>
>>> On Mon, Jun 12, 2017 at 2:05 PM, David Hart<
>>>> da...@hartbit.com
>>>> <mailto:da...@hartbit.com>>wrote:
>>>>
>>>>
>>>> On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:
>>>>> swift-evolution@swift.org>> wrote:
>>>>>
>>>>> Unfortunately, I think this proposal appears to be
>>>>> mistaken as to
>>>>> this key premise: Void was never (IIUC) meant to model
>>>>> the
>>>>> absence of arguments; it is a type with one possible
>>>>> value.
>>>>>
>>>>> If I recall, a number of conversations have been
>>>>> raised about
>>>>> Void being a typealias of (), and the definitive
>>>>> response has
>>>>> been that this falls into the ship-has-sailed category
>>>>> of
>>>>> out-of-scope changes.
>>>>>
>>>>> More generally, the recent spate of complaints about
>>>>> regressions
>>>>> to a particular coding style have to do with loss of
>>>>> implicit
>>>>> tuple splatting, the cure for which is a proper
>>>>> implementation of
>>>>> tuple splatting, not poking holes into settled parts
>>>>> of the type
>>>>> system.
>>>>>
>>>>
>>>> But you can’t deny that SE-0110 has also caused
>>>> regressions in the
>>>> use of Void as generic argument because Void is
>>>> modelled as the
>>>> empty tuple.
>>>>
>>>>
>>>> I'm not sure I understand this statement. Void is a synonym
>>>> for the
>>>> empty tuple, and that hasn't ever changed, so it can't be
>>>> the root
>>>> cause of any regressions.
>>>>
>>>> And tuple splatting will not fix those regressions.
>>>>
>>>>
>>>> How come? If `*` is the splat operator, then it would be
>>>> legal to call
>>>> a function `foo` that takes no arguments with `foo(*Void)`;
>>>> if
>>>> implicit tuple splatting returns in fully implemented form,
>>>> then it
>>>> would be legal to call it once again with `foo(Void)`.
>>>>
>>>> And contrary to what some people might think, this is
>>>> not an
>>>> “edge-case”. Most useful monads modelled with generics
>>>> have good
>>>> reasons to use Void:
>>>>
>>>> *The Result<T> monad:*Result<Void> represents the
>>>> result of an
>>>> operation with no return value
>>>> *The Promise<T> monad:*Promise<Void> represents the
>>>> result of an
>>>> asynchronous operation with no return value
>>>> *The Observable<T> monad (in functional reactive
>>>> programming):*Observable<Void> represents a stream of
>>>> events with
>>>> no values
>>>>
>>>> I use all three monads in my code and I’ve had to
>>>> modify a lot of
>>>> code when migrating to Swift 4 beta1 because of Void.
>>>>
>>>>
>>>> Can you give examples of the modifications needed during
>>>> migration?
>>>> From here, I can only see that the reason any code needs
>>>> modification
>>>> is the complete removal of implicit tuple splatting.
>>>> Nothing has
>>>> changed about Void being a synonym for the empty tuple;
>>>> even if you
>>>> rename Void, functions will still return () by some other
>>>> name, and
>>>> unless there is tuple splatting in some form, the migration
>>>> you
>>>> performed is inevitable.
>>>>
>>>> On Mon, Jun 12, 2017 at 12:15 John McCall via
>>>>> swift-evolution
>>>>> <swift-evolution@swift.org <mailto:
>>>>> swift-evolution@swift.org>> wrote:
>>>>>
>>>>>
>>>>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via
>>>>>> swift-evolution <swift-evolution@swift.org
>>>>>> <mailto:swift-evolution@swift.org>> wrote:
>>>>>>
>>>>>> Hi here,
>>>>>>
>>>>>> As I tested swift4 in xcode9b1 I noticed a lot of
>>>>>> regressions about tuples usage.
>>>>>>
>>>>>> After documenting myself about the changes which
>>>>>> happened, I
>>>>>> thought that they could be improved. Instead of
>>>>>> fighting
>>>>>> these propositions (which make sense), I wanted
>>>>>> create a few
>>>>>> proposal which would improve these recent changes
>>>>>> with a few
>>>>>> simple rules.
>>>>>>
>>>>>> My propositions are based on the recent decisions
>>>>>> and in the
>>>>>> continuation of SE-0110. The first one is about
>>>>>> Void.
>>>>>> Void is historically defined as the type of the
>>>>>> empty tuple.
>>>>>> The reason of this is that arguments were
>>>>>> initially
>>>>>> considered as tuple.
>>>>>>
>>>>>
>>>>> The dominant consideration here was always return
>>>>> types, not
>>>>> parameters. I'm not sure there was ever much
>>>>> point in
>>>>> writing Void in a parameter list, but whatever
>>>>> reasons there
>>>>> were surely vanished with SE-0066.
>>>>>
>>>>> Note that 'void' in C was originally exclusively a
>>>>> return
>>>>> type. ANSI gave it a new purpose it with void*,
>>>>> but the
>>>>> meaning is totally unrelated.
>>>>>
>>>>> John.
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:
>>>>> swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailma
>>>>> n/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailm
>>>>> an/listinfo/swift-evolution>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:
>>>>> swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailma
>>>>> n/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailm
>>>>> an/listinfo/swift-evolution>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
