RE: [sv-ec] Is "super" OK in constraint expressions?

>From: "Arturo Salz" <Arturo.Salz@synopsys.com>

>Allowing 'this' as a default method argument is complicated because it
>requires a context sensitive change to the existing rules.

It looks to me like all it requires is defining that the argument list
of a task/function is considered to appear inside the scope of the
task/function.  There would be some potential side-effects of this
that would have to be considered.

>            class X;
>
>                function void F( X q = this ); ... endfunction
>
>                function void G();
>
>                    X other = new();
>
>                    other.F();   // Is this the same as other.F(other)
>or other.F(this) ?
>
>    endfunction
>
>            endclass
>
> 
>
>I believe that the LRM currently requires the "other.F(this)"
>interpretation.

How could it?  The 'this' of function G is not visible in the scope
where function F is declared, so the default can't be referring to it.
I think you are confusing the scope where the function F is declared
with the scope where it is being called.  The 'this' of function G
is visible where F is called, but is not visible where it is declared.

If the default value is evaluated in the scope containing the subroutine
declaration, then 'this' is undefined.  If the default value is evaluated
inside the scope of the subroutine, then 'this' would be the 'this' of F,
which would make it other.F(other).  I don't see how it could be
other.F(this) under any rule based on the static scope of F.

Note that if the rules are changed to evaluate the default argument
inside the scope of the subroutine, there are other effects besides
allowing references to 'this'.  It might allow the defaults for one
argument to refer to the value of another argument.  This could then
get into issues of the order of evaluation of defaults with respect
to the passing in of non-default values, and with respect to each other.

But yes, this is a different issue from the one Bill Paulsen is raising.

Steven Sharp
sharp@cadence.com