Change equality operators about sass HOT 24 CLOSED

I feel like we had this discussion long ago when we were first introducing @if and booleans, but I don't remember what our reasoning was. I'm not opposed to the idea of using is and is not, but I do have two hesitations. First, I feel like having a more programmery punctuation-heavy operator calls attention to the fact that this is doing something different than CSS (although since boolean operations universally happen in the context of @if or possibly variable assignment, that's somewhat less relevant). The other worry I have is that this isn't a big enough issue that the cost of migrating existing stylesheets is outweighed by the benefit of the new syntax. I'm certainly not convinced of that, though.

from sass.

All I can say is something inside me cringes when I type == and != in a sass file. It's an asthetic reason and I'd like to change it sooner rather than later. It's a relatively easy thing to search and replace and it improves the overall readability of a file.

from sass.

I don't think you'd have to remove support for == and != I doubt you'd want to do anything else with them anytime soon, so just leave them as they are for backwards compatability

from sass.

Coffeescript has shown that is and == can live in harmony.

from sass.

I like where this is going and would like to help. Are we working off of pull 447?

from sass.

@ZhangBanger You could, or you could start a new PR.

from sass.

I'm adrusi on leaving: == and != left alone. If you want to add that functionality to is and is not that's fine, but no reason to remove the operators. ( the currently proposed 'eq' and 'ne' should work fine, but please leave the math operators, as they have it in Coffeescript.)

from sass.

CoffeeScript uses isnt operator as a synonym to !== which I find very pretty. I think if Sass would choose to follow a humanistic naming convention this one would be a more perfect option than an untidy is not. (However, considering Sass supports Boolean operators both of them should work.)

from sass.

I personally would prefer is not because it adds fewer keywords.

from sass.

@nex3 I'd Iike to introduce is and is not as the new equality operators in our next release. I'd like to deprecate == and != at that time. Objections?

from sass.

There are years and years worth of libraries, tutorials, codepens, and questions on SO that are going to reference the old style of equality operators. When the deprecation phase transitions to the error phase, people are going to be scratching their heads wondering why the code doesn't work.

This sounds like a terrible idea to me. Adding an alias is one thing, but I can't agree to breaking existing users' code for what is essentially a non-feature.

from sass.

@cimmanon It's a good point. But I would not just add an alias -- having two syntaxes for the same thing is just confusing.

people are going to be scratching their heads wondering why the code doesn't work

The error message would be very clear. Something like "The equality operator has been changed from == to is. E.g. $width is 4px" where the comparison listed would be their actual code's comparison printed out for them.

from sass.

I say 👎to this. I mean, "is" might be a pretty concept, but == is very common in languages and to remove support for it would be hellishly bad for new users and old users alike.

Sass developers are a lot more "programmery" than they were 5 years ago. Learning Sass is many people's first steps into programming, and == is pretty standard in languages.

I mean, we could support "===" and really make our users hate their lives.

from sass.

While is and is not is more declarative. If it is going to be a hard change with no alias to == or !=. There are too many large codebases out there that this change would effect negatively and create a technical debt problem for maintainers. There is always the argument that any code is a technical debt but this is a core syntax change and I think it should be an alias if its going to be implemented otherwise my vote is no.

from sass.

@scottdavis Like all changes, we would first deprecate the old operators for a release during which they could migrate over the existing code.

from sass.

The problem with that is that you lock some people into legacy and give them no future path. If they decide they can't upgrade for what ever reason. And it would create a support load on the sass community as legacy code backs up against that wall when it eventually does change.

The other issue is the internet will be littered with example code that people can't use.

from sass.

If they decide they can't upgrade for what ever reason.

We had this problem when we released Sass 3.0 and what we did was make upgrading automated via sass-convert, Basically, sass-convert would recursively parse using the old syntax (because it's only deprecated) and then print out the same files using the new syntax. Bonus: pretty printing occurs.

from sass.

What's the upside here? Because I don't see one. It was one thing when variable scoping was changed in 3.4 because there was a benefit to it (namely, variables aren't getting clobbered accidentally anymore). I just don't see what we're getting by taking away the familiar operators and replacing them with something foreign.

Even if I preferred the proposed operators over the existing ones, I would be opposed to this change. It just seems like it is change for the sake of change. While most CSS authors are not programmers, many of them are at least familiar with languages that use == and != for equality/inequality (JavaScript, PHP, etc.).

from sass.

I can't argue specifics without data to examine if the educational part of the 3.0 release was sufficient in letting people know about that update path. Im just speaking from experience in dealing with legacy software.

from sass.

What's the upside here?

I think it's a more attractive syntax. Always have. It feels more like CSS to me. Many language changes have been like this. We changed our variable sigil from ! to $, we changed variable assignment from = to :. None of these changes provided anything except an aesthetic benefit.

from sass.

Sorry, I would also not want to see this. I see == as meaning "equivalent/congruent to" rather than "the same entity", which is what "is" suggests. As was mentioned above, == is exceedingly common and intuitive for denoting equality. It also doesn't feel that out of place from CSS, especially when you have .attr-selector[type="text"] and not .attr-selector[type is "text"] occurring in vanilla CSS.

If anything needed to be changed to fit in more with CSS, I'd propose having = be an alias for == (because of the attribute selector syntax). But then again, I wouldn't even change that.

This just feels off to me:

$foo: (a: 1, b: 2);
$bar: (b: 2, a: 1);

$maps-equal: $foo is $bar; // this looks unintuitive

$maps-equal: $foo == $bar; // much better!

from sass.

I agree with @hcatlin @scottdavis. I don't see the user benefit. The following point stood out for me.

We had this problem when we released Sass 3.0 and what we did was make upgrading automated via sass-convert.

I don't believe this is a far comparison. Converting your code base is no longer enough, because of how our practices have evolved. It's possible (maybe likely?) teams are now depending on 10s of external dependencies (npm/bower) that can have varying levels of ongoing support.

from sass.

👍 I'm for is and is not and even isnt because it matches. It's just nicer to read and easier to type. I enjoy it in CoffeeScript and I'd like it in Sass too.

from sass.

I agree with the general sentiment here. There isn't enough value here to warrant such a huge change.

from sass.