Reversible Initializer

Evolution Pitches
21

So I guess you have a Tesla ? :)

So I could do

infix operator .. : MultiplicationPrecedence
infix operator .?. : MultiplicationPrecedence

func .. <T, U>(left: T, right: (T) -> U) -> U {
    return right(left)
}

func .?. <T, U>(left: Optional<T>, right: (T) -> U) -> Optional<U> {
    return left.map(right)
}

but there would still need to have something along "https://google.com"..URL.init
I don't really like this pattern, honestly... Doesn't seems very swifty to me...

I prefer "https://google.com".asUrl.asRequest but yes, seems not that different from piping.

22

It'd be interesting to see how all this ideas interact with init that is not originally single-argument, but have default arguments, which includes URLRequest(url:).

1 Like
23

Almost feels like [?]|> should be built into the language

24

Well reversible keyword would only be allowed on single argument initializers. I don’t see how else we could do.

25

If you want that exact syntax (a keyword on an initialiser), I think that would be better solved by some kind of macro or code-generation system.

I don't feel its usage is widespread enough right now to warrant making that code generation part of the language and compiler.

26

You mean it won't work with the URLRequest example?

28

No I think it would work. But you are right it would be quite complicated to check if the initializer is Something(something: x) or Something(x) ...

29

That’s my question. init is hardly single-argument by itself. For URLRequest.init(url:) it’s actually

init(url: URL, cachePolicy: URLRequest.CachePolicy = .useProtocolCachePolicy, timeoutInterval: TimeInterval = 60.0)

We could try to figure out one that has only one non-default argument. Though I start to feel the design is getting contrived.

Anyhow, what about ones with all default arguments? They have potential to have many single-argument forms.

1 Like
30

indeed... I guess the piping operator solution |> is more generic and can already be implemented manually... maybe reversible should be a protocol.

31

I really like this idea on a conceptual level. For the most part I think the asSomething syntax, and the reversible initializer solves this problem pretty well, also with regards to access control. Although, ideally I would really like to also see something more in the lines of implicit conversion.

That could allow syntax like:

let urlString: String = "www.swift.org"
let url = urlString as URL
let request = url as URLRequest

or as a one-liner:

let request = ("www.swift.org" as URL) as URLRequest

I don't know if this type of language feature has been discussed a lot in the past, but this could also potentially solve some syntactical friction when dealing with numbers, etc.

2 Likes
32

I must say this idea did went through my mind yesterday but seeing it like you showed it is sexy. However "as" is more a downcast like in MyViewController as UIViewController or a bridgecast like in NSString as String. for an upcast, maybe we should use another keyword like "into"?

let request = ("www.swift.org" into URL) into URLRequest

but when you look at it , "into" become a pipe operator that allows for the righthand parameter to automatically add .init to URL.init

as michelf proposed:

let urlRequest = string |> URL.init |> URLRequest.init

2 Likes
33

nice design，how about use to instead of into?
“...” to url to urlrequest !

34

I don't, but I'm taking driving lessons, and the car my driving school uses is a Tesla model 3.
It's the only car I've ever driven.