Hacker News Reader

Comment by skohan | Hacker News Reader

To echo a comment in the linked thread: what does the Apache license say about other implementations? If I want to create my own implementation of the Swift compiler, or create another language with optional chaining, would this license protect me? Or does it only protect the use of this implementation?

View on HN

Well, given that Rust and C# also have these features I think the likelihood that the patent is upheld is unlikely. I guess they could threaten you with it since lawyers are expensive, but it seems silly to me.

Groovy had null (optional) chaining

https://therealdanvega.com/blog/2013/08/20/groovys-null-safe...

and Kotlin https://kotlinlang.org/docs/reference/null-safety.html

In Apache Groovy you need to write `a?.b?.c` for nullsafe chaining on both `b` and `c`. In the past, its project managers have discussed propagating nullsafety down the chain so you'd only need to write `a?.b.c` to make both `b` and `c` nullsafe, but they've never implemented it.

Not sure if that's in Rust, Kotlin, C#, or Ruby, or in Groovy's Antlr 4 parser.

FWIW Rust does not have optionals chaining, except in the monadic sense (in which case ML and Haskell have optionals chaining).

That is, in Rust you'd use Option::map or Option::and_then, there is no equivalent to the `?.` and `?[]` operators, the `?` operator (or `try!` macro) is a shortcut for an "unwrapping guard".

Right, but isn't `?.` just syntactic sugar on `Option::and_then`? Is this a patent on a piece of syntactic sugar, or is it a patent on the idea of chaining optional values?

Ruby does seem to have the exact thing: http://mitrev.net/ruby/2015/11/13/the-operator-in-ruby/

I'm also pretty sure I had it in C# before Swift was introduced.

one thing though, in swift you can actually mutate fields using optional chaining, e.g. person?.name = "Bob". you can't do that in c#. not sure about rust but in scala you would unwrap the optional with a foreach or something.

In Groovy you can mutate through optional (null-safe) chaining, eg:

    x = [ foo: [ bar: 1] ]
    x.foo.bar // 1
    x.boo?.bar // null because x.boo is null
    x.boo?.bar = 1 // succeeds even though x.boo is null
    x.boo // still null

I knew I had seen this somewhere else. I don't understand why C# doesn't support this since most C# code is mutable anyway. I can see why it doesn't fit well with functional languages but C# usually espouses pragmatism over purity and having this would clean up a lot boilerplate null checking.

Yeah and using optionals in rust vs swift makes rust super annoying to use because of that.

Do Rust and C# implement these features the same exact way as Apple claims in this patent?

Patents protect how you something, not what you do.

Technically speaking, C# does not have optionals so I don't think it can be argued that C# violates the patent unless it's generalized to include null propagation which operates on reference types.

C# Nullable<T> is optional for all purposes (a struct with .Value and .HasValue), it's just restricted to value types.

right, c#'s nullable types are the ultimate in syntactic sugar in that you can just use them like regular value types in most places without realizing they are monads underneath.

I wouldn't say they have substantially more syntactic sugar than other languages with the same. If you need to use them in the context that is not optional, you need to use HasValue/Value, or casts, or (since recent versions) pattern matching to extract the value.

The only special sauce I can think of is that C# also implements null-lifting for most operators in the language, which is not necessarily a good thing because it treats null as "unknown" rather than "missing" - e.g. a + b works on int?, and will produce null if either a or b is null. With Boolean operators, it's even clearer - false & null is false, true | null is true, but true & null is null, and false | null is null. But quite often this is not what I actually want! If null really means that the value is missing, then a + b shouldn't even compile for optionals. But in practice, I'd say that vast majority of all uses of Nullable are to denote missing rather than indeterminate values.

The Apache license covers derived works.

So if you fork Swift, you’re covered. If you don’t form Swift, then you’re not covered.

Note that the Apache license is much stronger / better than the PATENTS.txt files accompanying projects like those from Microsoft / Facebook, because those usually don’t cover forks and are designed to protect the parent company.

And what about languages like JavaScript and Kotlin which have already integrated the optional-chaining operator themselves?

This is interesting because it raises questions about what is a fork. Can I fork Swift and throw out everything except for the patented part and then merge it with my project?

Judges don't typically fall for stuff like that. Just because you created something by using the fork process, the end result after your giant purge isn't recognizable as a fork of Swift.

Reply on news.ycombinator.com