Re: Re: Strict Relational Operators

Perhaps a simpler approach (short of type systems) would be a single binary operator that returned true only when the Type() of each operand was the same? In other words (using "=@=@=" to avoid bikeshedding on the syntax itself): `a =@=@= b` would be equivalent to `(a === null || b === null) ?

Re: Re: Strict (non-coercing) expressions

“use …”, of course! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict (non-coercing) expressions

On Thu, Apr 13, 2017 at 11:08 AM, Bruno Jouhier wrote: > I like the idea of a block level annotation. Lighter and more practical > than a new set of operators. Module level would be nice too. OTOH > expression level feels a bit like overkill. > > Why not turn this into a more

Re: Re: Strict (non-coercing) expressions

I like the idea of a block level annotation. Lighter and more practical than a new set of operators. Module level would be nice too. OTOH expression level feels a bit like overkill. Why not turn this into a more general _pragma_ syntax then? This would allow us to control other special

Re: Re: Strict Relational Operators

That would seem to make more sense. At the end of the day, for me, I just don't much value in adding new syntax for operators to do this. The only time I can think of in my own code where this would be useful (in the sense that it would have avoided some extra type check to ensure things work as I

Re: Re: Strict Relational Operators

Yeah. I suggested that if we aren't doing symbolic operators but rather functions or something else, they should result in `undefined` for mixed types, so you can differentiate if appropriate. (Symbolic operators like `<=<` would need to be consistent with `===` and `!==`, though, which don't,

Re: Re: Strict Relational Operators

Put another way === is useful because you test for strict equality. Either it is or is not what you need. But always returning false when comparing things with less than or greater than doesn't ensure that you got what you want. A false value can be success as much as a true value. On Apr 13,

Re: Re: Strict Relational Operators

Strict expressions. In the case of always returning false, that seems like little help in avoiding bugs to me, since code flow always continues... On Apr 13, 2017 7:35 AM, "T.J. Crowder" wrote: > James, are you commenting on felix's idea of strict expressions

Re: Re: Strict Relational Operators

James, are you commenting on felix's idea of strict expressions (in which case, I suggest the other thread: https://esdiscuss.org/topic/strict-non-coercing-expressions), or strict relational operators? Other than felix's strict expressions, I don't think anyone was suggesting that strict

Re: Re: Strict Relational Operators

I am of the opinion that this isn't really a worthwhile effort in the context of a non-typed language. There are several issues. First, it doesn't actually create any parity with ===. Triple equals never throws an error, it just returns false if the types are unequal. These constructs would

Re: Re: Strict Relational Operators

I've started a separate thread to discuss felix's idea of an expression mode making all operators within it non-coercing (as it's rather more broad than this topic): https://esdiscuss.org/topic/strict-non-coercing-expressions -- T.J. Crowder On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine

Strict (non-coercing) expressions

In the thread on [strict relational operators][1], felix [suggested][2] an expression mode affecting all operators: > Maybe every operator can have a non-coercing variant? > > One possible syntax is to have a modifier on operators > >x = a (<) b (+) c (&&) (!)d; > >if (x (!=) y) ... > > >