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/RxSwift/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/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/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 <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
