New feature in v3: cast!

[Alan DeKok]

Brian Candler wrote:
> So if I understand you rightly, you're saying that the unlang expressions
> 
>    Framed-IP-Address == 127.0.0.1
> 
> and
> 
>    Framed-IP-Address == "127.0.0.1"
> 
> are treated identically - it's the type of the LHS which makes a difference,
> and no distinction is made between an IP literal and a string literal. Is
> that correct?

  Yes.

> Is there a fundamental reason why literal values can't have types?

  Until a month ago, the conditions were parsed *every time* they were
evaluated.  Now, they're parsed once, and a data structure is stored.

  So... it becomes possible to do type-specific checks.  i.e.

	Framed-IP-Address == "127.0.0.1"

  is wrong.  Unless the right-side is something like "%{sql: ...}"

> The canonical example would be the difference between 1 and "1". Say:
> 
>     if (Acct-Session-Time < 100)
> 
> But presumably
> 
>     if (Acct-Session-Time < "100")
> 
> is handled the same today (i.e. the "100" is converted to an integer because
> of the LHS type).

  Yes.

> ... which again implies this is parsed exactly the same as
> 
>     if ("127.0.0.1" < "127.0.0.2")

  Right now, yes.

> But there must be something else going on, because on the LHS at least,
> Framed-IP-Address is not parsed the same as "Framed-IP-Address"

  Well, the parser isn't *completely* idiotic.  Just *mostly* idiotic.

> That's pretty different to most languages though, were A == B compares the
> values of A and B, and & gives you a reference to the variable; you want to
> compare the values, not the references.

  I'm open to a better alternative...

  It's hard to come up with *new* syntax, because I'm wary of breaking
existing systems.  i.e.

	Framed-Pool == bar

  is allowed today.  But "bar" isn't the correct name for an attribute.
 How do we disambiguate the two possibilities?

> Having said that, I seem to remember that C++ does magic dereferencing,
> converting references to values where required.  But the main purpose of
> taking a reference is to allow a variable to be assigned to at a distance.

  Which isn't possible in unlang.  So.. the "&" is syntactic sugar for
"the contents of the attribute", and not "a reference to an attribute"

>> The
>> v2 unlang code would require you to do:
>>
>> 	if (User-Name == "%{Filter-Id}") {
> 
> Ah yes, because of things like Acct-Status-Type == Start, where the RHS has
> to be considered as an enumerated value rather than another attribute.

  Yes.

  Alan DeKok.