Hacker News Reader

Comment by kbsletten | Hacker News Reader

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.

View on HN

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.

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

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.

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.

Reply on news.ycombinator.com