On Thu, Jul 26, 2018 at 1:09 AM, Steven D'Aprano <steve@pearwood.info> wrote:

On Thu, Jul 26, 2018 at 01:02:47AM -0400, Amit Green wrote:

> 3. The problem is way deeper than simply adding '?.' and other operators.
> For real use cases, you also need to say "how far" the an operator can
> "spread" -- and this is real hard to solve.

Why do you think that is the case? No other operators "spread". Why
should these?

If you take 'a?.b.c' then if the first '?.' yields none, logically you don't want to evaluate the second '.'; otherwise you have to write:

a?.b?.c -- And this starts to look like line noise.

If you also implemented a concept such as use non-aware operators in function calls: such as:

f(a, b?, c) -- which would mean collapse the whole thing out of non-existance if 'b' yields none (i.e.: don't call function f) -- how far does this spread? Outside of f, if you then write:

f(a, b?, c).d.e

Does this also mean don't evaluate the '.d' & '.e' ?

And both of these examples are from *REAL* uses cases in my code I would want to use none-aware operators.

> 4. Coming up with a readable syntax that doesn't look like line noise is
> really hard; and very subjective.

Define "line noise".

Is a.b.c syntax line noise?

Is a**b**c syntax line noise?

Is a == b == c line noise?

These examples, from python, all look great & are very readable. Which is why python is such a great language :)

Simple non-aware operators are also very readable, such as: a?.b

This starts to become unreadable & line noise: a?.b.c.d ?? "hi".

Again, though it is subjective -- as is clearly evident by the discussions in this group.

My simple point above is -- I really do want this feature -- but having tried for days, I can't come up with a really clean syntax to capture all of my *OWN* use cases ... let alone others...

Anyway, as I said, I think we have more important issues to address right now, than this very difficult issue & I'll write up more tomorrow.