Typesafety: assert function to fail at compile time

[slorber]

Hi,

What I'd like to do is something like:

.background-clip(@value) when (@value = border-box),
                              (@value = padding-box),
                              (@value = content-box),
                              (@value = inherit)
{
    -webkit-background-clip: @value;
       -moz-background-clip: @value;
            background-clip: @value;
}

When the background-clip is called with a wrong value, instead of ignoring that value, it could be nice to make the compilation fail.

Is it currently possible? or could it be in the future?

It would be really great to have a syntax to tell that the guard is a "compilation guard" and not simply "ignore-guard"

One simple solution i can think of is using a function that may fail. Something like:

.background-clip(@value) when (oneOf(@value,"border-box","padding-box","content-box","inherit")
{
            background-clip: @value;
}

The idea is that the function acts like an "assertion" that may make the compilation fail.

As far as I see there are already such functions that can make the compilation fail.

It would be nice to have more compilation safety with a oneOf function.

There are probably other useful options, like ensuring a list contains only know values.

For example when dealing with interaction modes, which can generally be mouse and/or touch. We have to handle special cases because the :hover is not possible on devices with only touch support.

.myMixin(@interactionMode) when (listOf(@interactionMode,"touch","mouse")
{

   div.someButton {
        & when (contains(@interactionMode,"touch")) {
            // ...
        }
        & when (contains(@interactionMode,"mouse"))  {
           &:hover {
                       // ...
           }
        }
        & when (contains(@interactionMode,"mouse","touch")) {
            // ...
        }
   }
}

The contains() function would be useful there :)

Maybe we could also pass as mixin arguments complex json objects and assert in functions that they have a certain "shape"

I don't know which functions would be useful exactly but I think it would be a nice progress for less to have more "typesafety".

[slorber]

Notice I tried to use this hack to declare js functions in less without success (inside a guard)

#637

[slorber]

Another idea could be this kind of syntax:

.mixin (@a) when (lightness(@a) >= 50%) {
  background-color: black;
}
.mixin (@a) when (lightness(@a) < 50%) {
  background-color: white;
}
.mixin (@a) {
  fail("This mixin can't be called with this value",@arguments);
}

[slorber]

Ok so I think @seven-phases-max has an answer for everything :)

As far as I understand I can provide custom functions by using a less plugin.

Here is a List plugin from which I can inspire myself to build some kind of "less-assertions-plugin"

https://github.com/seven-phases-max/less-plugin-lists

[SomMeri]

This might be related to #1459 . It is not exactly the same thing, but has similar goal.

[seven-phases-max]

I think it's easier to introduce some "assert" function and use it like:

@unused: assert(@condition, "doh!");

instead of inventing some special syntax.

Taking the first use-case into account, less-plugin-lists misses some index-of function or so, to be used together with such assert (currently functions there follow "Don't raise a error if the function fails" convention). But sure one easily can make some function to fit either needs.
(Still I would not mind a built-in assert).

[slorber]

Yes a built-in assert would permit to reuse existing functions that do not throw!

Could we do something like this?

.mixin (@list) when (assert( lengt(@list) < 3 )) {
  ...
}

[slorber]

@seven-phases-max I've done some tests and it seems that less can support quite complex expressions in a when clause, so definitively some simple assertion functions would be a huge win!

However I'm still interested in a case to make less compilation simply fail anyway.

See for example how ScottS here had the idea to call a mixin that does not really exist to make less fail (option 3): http://stackoverflow.com/questions/20959298/enums-documentation-with-less-mixins/21052115

Example where this can be needed is when there is a simple case for which you can to assert.
For example:

.complexMixin(@list,@list2) when ( sin(length(@list)) < cos(length(@list2)) ) {
  // not fail
}
.complexMixin(@list,@list2) when ( sin(length(@list)) > cos(length(@list2)) ) {
  // not fail
}
.complexMixin(@list,@list2) {
  fail("the cos and sin can't be equal!");
}

I mean I want to be able to express switch / pattern matching expressions where the default unhandled case should never happen (pattern often used to fail fast):

switch (value) {
  case "x" ...
  case "y": ...
  default: throw new Error("fail!");
}

[slorber]

So I tried to make a plugin but not really successfully :'( not sure to understand how to make it work and even how to make unit tests. It seems the test does not find my new function:

https://github.com/slorber/less-plugin-assert/

[seven-phases-max]

Well, your mistake there is that you assume that Less true is equal to JS true - it's not actually.
All Less values (colors, numbers, strings of various types, and logical values in the end) are represented with dedicated JS objects (Color, Dimension, etc. you'll find in less.tree). Thus in your assert impl. you would need to compare the condition value to less.tree.True constant rather than using !condition).

---

For your particular example, however, it's easier to write just a error (or debug-break or fail or whatever you name it function) to throw a error unconditionally since you're going to use it with when statement anyway. (assert function is supposed to evaluate the condition on its own but since logical statements are only possible inside when statements and cannot be passed to functions, things like assert(length(@list) < 1, "doh!") are not quite possible currently).
In other words, in your plugin just write a function like:

error: function(message) {
    throw {
        type: "Whatever",
        message: message.value // note the message arg is of type less.tree.Quoted (not JavaScript String)
    };
}

and then use it like:

.complexMixin(@list, @list2) when (sin(length(@list)) < cos(length(@list2))) {
    // ok
}
.complexMixin(@list, @list2) when (sin(length(@list)) > cos(length(@list2))) {
    // ok
}
.complexMixin(@list, @list2) when (default()) {
    unused: error("the cos and sin can't be equal!");
}

[slorber]

ok thanks for the explanation :)

that seems not very better than the "mixin does not exist" than ScottS proposed on stackoverflow unfurtunatly

[seven-phases-max]

that seems not very better than the "mixin does not exist"`

That was your code not mine :)

For your initial example me would start with something like:

.background-clip(@value) when 
    (at(l(border-box, padding-box, content-box, inherit), @value) = ~'') {
        // ...
}

then it's not a problem to derive a function to remove redudant l(), = ~'' and/or generate a error in place.
I.e. it's just a matter of deciding what the function of interest should actually do, i.e. is it is-value-in-list returning true or false, or ensure-value-in-list generating a error if not, index-of so one could compare it with > 1 etc. and so on.

[seven-phases-max]

Btw., thinking of the initial example yet more I recall one more method (w/o bothering with custom functions) to generate a bit more readable error message with a bit less verbose code (if compared to the method suggested in the SO Q above): [1].

[rjgotten]

one more method

Using the pattern matching mechanic on an inner mixin; clever!