[Bug c++/48934] New: no rejection reason given for SFINAE

[Bug c++/48934] New: no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

           Summary: no rejection reason given for SFINAE
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: redi@gcc.gnu.org
                CC: froydnj@gcc.gnu.org


int foo(int);

template<typename T>
  struct sfinae
  { };

template<>
  struct sfinae<float>
  {
      typedef double type;
  };

template<typename T>
  typename sfinae<T>::type
  foo(T t)
  { return t; }

struct Bar { };

Bar b = foo( Bar() );


The error prints the two candidate functions and reason they weren't viable (I
love this feature, thanks Nathan!)

reason.cc:20:20: error: no matching function for call to 'foo(Bar)'
reason.cc:20:20: note: candidates are:
reason.cc:1:5: note: int foo(int)
reason.cc:1:5: note:   no known conversion for argument 1 from 'Bar' to 'int'
reason.cc:15:10: note: template<class T> typename sfinae::type foo(T)

But no reason is given for the template.

I think the reason Clang++ gives is pretty good:
note: candidate template ignored: substitution failure [with T = Bar]

The key points to include in the reason are the template arguments and that
substitution failed (more formally, type deduction failed because substitution
resulted in an invalid type)

I've only checked this with 4.6 so apologies if it's already been improved on
trunk.

[Bug c++/48934] no rejection reason given for SFINAE

[froydnj at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #1 from froydnj at codesourcery dot com <froydnj at codesourcery dot com> 2011-05-09 11:53:58 UTC ---
On Mon, May 09, 2011 at 11:39:35AM +0000, redi at gcc dot gnu.org wrote:
> int foo(int);
> 
> template<typename T>
>   struct sfinae
>   { };
> 
> template<>
>   struct sfinae<float>
>   {
>       typedef double type;
>   };
> 
> template<typename T>
>   typename sfinae<T>::type
>   foo(T t)
>   { return t; }
> 
> struct Bar { };
> 
> Bar b = foo( Bar() );
> 
> 
> The error prints the two candidate functions and reason they weren't viable (I
> love this feature, thanks Nathan!)
> 
> reason.cc:20:20: error: no matching function for call to 'foo(Bar)'
> reason.cc:20:20: note: candidates are:
> reason.cc:1:5: note: int foo(int)
> reason.cc:1:5: note:   no known conversion for argument 1 from 'Bar' to 'int'
> reason.cc:15:10: note: template<class T> typename sfinae::type foo(T)
> 
> But no reason is given for the template.
> 
> I've only checked this with 4.6 so apologies if it's already been improved on
> trunk.

I submitted a patch for this:

http://gcc.gnu.org/ml/libstdc++/2011-02/msg00009.html

I need to clean it up a bit and possibly fix some testsuite failures.
Does that patch do what you want?

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-09 12:03:48 UTC ---
I forgot about that mail - I'll try the patch and get back to you, thanks

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-09 12:18:12 UTC ---
That patch makes no difference for the example in this PR

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-09 14:05:06 UTC ---
Another example:

  template<typename T> struct S1 { typedef char type; };

  template<typename T>
    typename S1<T>::type
    foo(typename S1<T>::typo)
    { return t; }

  char c = foo<int>(1);

Here the return type is valid, but the parameter is not ("typo" vs "type").
Ideally the diagnostic would indicate that, which would help when the template
arguments are substituted in more than one place.


My dream compiler would tell me exactly where it failed e.g.

  template<bool> struct S2 { typedef char type; };

  template<typename U> struct S3 { static const bool V = true; };

  template<typename T>
    typename S2<S3<T>::val>::type   // no 'val'
    foo(T t)
    { return t; }

  char c = foo(1);

This fails because "S3<T>::val" is an invalid expression ("val" vs "V")

My dream compiler would tell me which sub-expression was invalid, as this could
be a huge help when debugging complex SFINAE cases with nested expressions and
types.

I realise that might be very difficult to do and that as a library implementor
my wishlist may not be typical of most users. Simply saying something like
"substitution failed" would already be a nice improvement.

[Bug c++/48934] no rejection reason given for SFINAE

[froydnj at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #5 from froydnj at codesourcery dot com <froydnj at codesourcery dot com> 2011-05-09 15:38:14 UTC ---
Thanks for checking.  I'll attempt to the make the patch do something
intelligent on at least the original testcase and this:

>   template<typename T> struct S1 { typedef char type; };
> 
>   template<typename T>
>     typename S1<T>::type
>     foo(typename S1<T>::typo)
>     { return t; }
> 
>   char c = foo<int>(1);
> 
> Here the return type is valid, but the parameter is not ("typo" vs "type").
> Ideally the diagnostic would indicate that, which would help when the template
> arguments are substituted in more than one place.

Thanks for the additional testcases!

> I realise that might be very difficult to do and that as a library implementor
> my wishlist may not be typical of most users. Simply saying something like
> "substitution failed" would already be a nice improvement.

"substitution failed" will probably be the default message if we can't
provided anything more intelligent.

[Bug c++/48934] no rejection reason given for SFINAE

[froydnj at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #6 from froydnj at codesourcery dot com <froydnj at codesourcery dot com> 2011-05-09 16:10:51 UTC ---
On Mon, May 09, 2011 at 02:08:05PM +0000, redi at gcc dot gnu.org wrote:
>   template<typename T> struct S1 { typedef char type; };
> 
>   template<typename T>
>     typename S1<T>::type
>     foo(typename S1<T>::typo)
>     { return t; }
> 
>   char c = foo<int>(1);

Running this example given an error about `t' not being declared.  What
did you mean to return there?  Or is that part of the point?

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-09 16:24:51 UTC ---
(In reply to comment #6)

Oops, no, that's a mistake, the parameter should be named 't'

  template<typename T> struct S1 { typedef char type; };

  template<typename T>
    typename S1<T>::type
    foo(typename S1<T>::typo t)
    { return t; }

  char c = foo<int>(1);

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-09 16:28:51 UTC ---
The point of that example is that even clang's "substitution failed" could be
improved, because T is substituted successfully into the return type
"S1<T>::type" but not into the parameter type "S1<T>::typo" (in the general
case they wouldn't both use S1 and there could be several parameters)

So a better reason would be "substitution failed for parameter 1" but I don't
know how easy that is, if it's even possible in the current G++ codebase

[Bug c++/48934] no rejection reason given for SFINAE

[froydnj at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

Nathan Froyd <froydnj at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #9 from Nathan Froyd <froydnj at gcc dot gnu.org> 2011-05-09 17:10:31 UTC ---
(In reply to comment #8)
> The point of that example is that even clang's "substitution failed" could be
> improved, because T is substituted successfully into the return type
> "S1<T>::type" but not into the parameter type "S1<T>::typo" (in the general
> case they wouldn't both use S1 and there could be several parameters)
> 
> So a better reason would be "substitution failed for parameter 1" but I don't
> know how easy that is, if it's even possible in the current G++ codebase

It is possible; it's just a bit tedious, since you'd need to thread the
unification_info all the way through template substitution, not just function
type deduction.  I don't know how Jason would feel about the extra parameter
and corresponding call overhead to tsubst, though.  Jason?

(IIUC, doing this would also enable you to precisely report which
sub-expression substitution failed in.)

The hackish way of doing this would be to notice during deduction that
substitution of a function type failed, then go back and substitute piece-wise
into return type and argument types until you find the failing type.  That
could be done without the changes above, but it'd be a bit gross.

[Bug c++/48934] no rejection reason given for SFINAE

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> 2011-05-09 18:17:17 UTC ---
(In reply to comment #9)
> The hackish way of doing this would be to notice during deduction that
> substitution of a function type failed, then go back and substitute piece-wise
> into return type and argument types until you find the failing type.  That
> could be done without the changes above, but it'd be a bit gross.

It sounds to me like that would be both simpler and better than trying to pass
back information about why the substitution failed.  If we get to the point
where we're trying to explain substitution failure, we can just do the
substitution again with tf_warning_or_error and we'll find out exactly what the
problem is with the usual error messages.

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-09 19:13:45 UTC ---
(In reply to comment #11)
> 
> foo.C:blahblah: error: no matching function for call to foo
> foo.C:blahblah: note: candidate is foo(blahblah)
> foo.c:blahblah: note:   substitution failed for parameter `F'
> 
> At least, that's what I understood Jonathan asking for--perhaps he
> wanted something more detailed about why substitution failed, which is a
> debate for another time, I think.

I would love to get more information, but I'd be very happy with the diagnostic
above (that's already better than I'd get from any compiler I've tried)

This PR is really just to get *anything* printed, so just a basic "substition
failed" with no mention of which template parameter failed would be enough to
resolve this IMHO.

Improving on that would be a nice-to-have, for a later date.

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-09 19:16:39 UTC ---
(In reply to comment #12)
> 
> This PR is really just to get *anything* printed, so just a basic "substition
> failed" with no mention of which template parameter failed would be enough to
> resolve this IMHO.

To clarify: I would like to get the usual list of template args e.g. "[with T =
foo, U = bar]" but I don't mind if it doesn't say for which one substitution
failed.

[Bug c++/48934] no rejection reason given for SFINAE

[froydnj at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #11 from froydnj at codesourcery dot com <froydnj at codesourcery dot com> 2011-05-09 18:59:55 UTC ---
On Mon, May 09, 2011 at 06:26:44PM +0000, jason at gcc dot gnu.org wrote:
> > The hackish way of doing this would be to notice during deduction that
> > substitution of a function type failed, then go back and substitute piece-wise
> > into return type and argument types until you find the failing type.  That
> > could be done without the changes above, but it'd be a bit gross.
> 
> It sounds to me like that would be both simpler and better than trying to pass
> back information about why the substitution failed.  If we get to the point
> where we're trying to explain substitution failure, we can just do the
> substitution again with tf_warning_or_error and we'll find out exactly what the
> problem is with the usual error messages.

I'm not sure what you suggest is a win.  The desired (or, at least,
consistent with what we do now) behavior is to say:

foo.C:blahblah: error: no matching function for call to foo
foo.C:blahblah: note: candidate is foo(blahblah)
foo.c:blahblah: note:   substitution failed for parameter `F'

At least, that's what I understood Jonathan asking for--perhaps he
wanted something more detailed about why substitution failed, which is a
debate for another time, I think.

If I understand your proposal correctly, we'd get something more like:

foo.C:blahblah: error: no matching function for call to foo
foo.C:blahblah: note: candidate is foo(blahblah)
foo.C:blahblah: error: [some explanation]

which doesn't seem quite right.

To make the hack suggestion more concrete, we currently have,
pt.c:fn_type_unification:

    /* All is well so far.  Now, check:

       [temp.deduct]

       When all template arguments have been deduced, all uses of
       template parameters in nondeduced contexts are replaced with
       the corresponding deduced argument values.  If the
       substitution results in an invalid type, as described above,
       type deduction fails.  */
    {
      tree substed = tsubst (TREE_TYPE (fn), targs, tf_none, NULL_TREE);
      if (substed == error_mark_node)
    return 1;

and I was proposing to replace the bare 'return 1' with something more
like:

       {
         /* Check to see if return types were the reason substitution
            failed.  */
         tree t = <tsubst on return types>
         if (t == error_mark_node)
           return unify_return_type_substitution_failure ...

         /* Loop over the arguments of TREE_TYPE (FN) and TARGS.  */
         foreach ...
           {
              tree t = <tsubst on argument type>
              if (t == error_mark_node)
                return unify_argument_substitution_failure ....
           }

and then we would handle return_type_substitution_failure or
argument_substitution_failure in call.c's error handling.

I'm sure that code doesn't work as-is, but hopefully you get the idea.

This is getting a bit convoluted.  I thought the original patch posted
back in February was pretty sane, but as I look into a little more, it's
starting to get hairy.

[Bug c++/48934] no rejection reason given for SFINAE

[froydnj at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #14 from froydnj at codesourcery dot com <froydnj at codesourcery dot com> 2011-05-09 19:20:49 UTC ---
On Mon, May 09, 2011 at 07:16:49PM +0000, redi at gcc dot gnu.org wrote:
> > foo.C:blahblah: error: no matching function for call to foo
> > foo.C:blahblah: note: candidate is foo(blahblah)
> > foo.c:blahblah: note:   substitution failed for parameter `F'
> > 
> > At least, that's what I understood Jonathan asking for--perhaps he
> > wanted something more detailed about why substitution failed, which is a
> > debate for another time, I think.
> 
> I would love to get more information, but I'd be very happy with the diagnostic
> above (that's already better than I'd get from any compiler I've tried)
> 
> This PR is really just to get *anything* printed, so just a basic "substition
> failed" with no mention of which template parameter failed would be enough to
> resolve this IMHO.

OK, well that's easy enough to provide, then. :)

[Bug c++/48934] no rejection reason given for SFINAE

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> 2011-05-09 20:10:23 UTC ---
(In reply to comment #11)
> If I understand your proposal correctly, we'd get something more like:
> 
> foo.C:blahblah: error: no matching function for call to foo
> foo.C:blahblah: note: candidate is foo(blahblah)
> foo.C:blahblah: error: [some explanation]
> 
> which doesn't seem quite right.

Having it use the error tag rather than note is suboptimal, but I think getting
helpful error messages with relatively minimal compiler changes outweighs that
aesthetic concern.  :)

[Bug c++/48934] no rejection reason given for SFINAE

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #16 from Jason Merrill <jason at gcc dot gnu.org> 2011-07-17 02:34:15 UTC ---
Author: jason
Date: Sun Jul 17 02:34:10 2011
New Revision: 176365

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176365
Log:
    PR c++/45329
    PR c++/48934
    * cp-tree.h (fn_type_unification): Add `bool' parameter.
    * pt.c (enum template_base_result): Define.
    (unify_success, unify_unknown): Define.
    (unify_parameter_deduction_failure): Define.
    (unify_invalid, unify_cv_qual_mismatch, unify_type_mismatch): Define.
    (unify_parameter_pack_mismatch): Define.
    (unify_parameter_pack_inconsistent): Define.
    (unify_ptrmem_cst_mismatch, unify_vla_arg): Define.
    (unify_expression_unequal, unify_inconsistency): Define.
    (unify_method_type_error, unify_arity): Likewise.
    (unify_too_many_parameters, unify_too_few_parameters): Define.
    (unify_arg_conversion, unify_no_common_base): Define.
    (unify_illformed_ptrmem_cst_expr): Define.
    (unify_substitution_failure): Define.
    (unify_inconsistent_template_template_parameters): Define.
    (unify_template_deduction_failure): Define.
    (unify_template_argument_mismatch): Define.
    (unify_overload_resolution_failure): Define.
    (comp_template_args_with_info): New function, split out from...
    (comp_template_args): ...here.    Call it.
    (deduction_tsubst_fntype): Add `complain' parameter'.  Pass it
    to tsubst.
    (unify): Add `explain_p' parameter.  Pass to all relevant calls.
    Call above status functions when appropriate.
    (resolve_overloaded_unification, try_one_overload): Likewise.
    (type_unification, type_unification_real): Likewise.
    (unify_pack_expansion): Likewise.
    (get_template_base, try_class_unification): Likewise.
    (get_bindings, more_specialized_fn): Pass false to unification
    calls.
    (get_class_bindings, do_auto_deduction): Likewise.
    (convert_nontype_argument): Likewise.
    (fn_type_unification): Likewise.  Pass tf_warning_or_error if
    explain_p.
    (get_template_base): Add `explain_p' parameter and pass it to
    try_class_unification.    Return an enum template_base_result.
    * class.c (resolve_address_of_overloaded_function): Pass false to
    fn_type_unification.
    * call.c (enum rejection_reason_code): Add new codes.
    (struct rejection_reason): Add template_unification field.
    Add template_instantiation field.
    (template_unification_rejection): Define.
    (template_unification_error_rejection): Define.
    (template_instantiation_rejection): Define.
    (invalid_copy_with_fn_template_rejection): Define.
    (add_template_candidate): Pass false to unify.
    Provide more rejection reasons when possible.
    (print_template_unification_rejection): Define.
    (print_arity_rejection): Define, split out from...
    (print_z_candidate): ...here.  Add cases for new rejection
    reasons.

Added:
    trunk/gcc/testsuite/g++.dg/overload/template5.C
    trunk/gcc/testsuite/g++.dg/template/overload12.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/class.c
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/cpp0x/decltype29.C
    trunk/gcc/testsuite/g++.dg/cpp0x/error4.C
    trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice2.C
    trunk/gcc/testsuite/g++.dg/cpp0x/nullptr15.C
    trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
    trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
    trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
    trunk/gcc/testsuite/g++.dg/cpp0x/sfinae11.C
    trunk/gcc/testsuite/g++.dg/cpp0x/sfinae26.C
    trunk/gcc/testsuite/g++.dg/cpp0x/temp_default2.C
    trunk/gcc/testsuite/g++.dg/cpp0x/trailing4.C
    trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex3.C
    trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex4.C
    trunk/gcc/testsuite/g++.dg/cpp0x/variadic105.C
    trunk/gcc/testsuite/g++.dg/cpp0x/vt-37737-2.C
    trunk/gcc/testsuite/g++.dg/ext/vla2.C
    trunk/gcc/testsuite/g++.dg/other/ptrmem10.C
    trunk/gcc/testsuite/g++.dg/other/ptrmem11.C
    trunk/gcc/testsuite/g++.dg/overload/unknown1.C
    trunk/gcc/testsuite/g++.dg/template/conv11.C
    trunk/gcc/testsuite/g++.dg/template/deduce3.C
    trunk/gcc/testsuite/g++.dg/template/dependent-expr5.C
    trunk/gcc/testsuite/g++.dg/template/error45.C
    trunk/gcc/testsuite/g++.dg/template/friend.C
    trunk/gcc/testsuite/g++.dg/template/incomplete2.C
    trunk/gcc/testsuite/g++.dg/template/local4.C
    trunk/gcc/testsuite/g++.dg/template/local6.C
    trunk/gcc/testsuite/g++.dg/template/operator9.C
    trunk/gcc/testsuite/g++.dg/template/ptrmem2.C
    trunk/gcc/testsuite/g++.dg/template/sfinae2.C
    trunk/gcc/testsuite/g++.dg/template/ttp25.C
    trunk/gcc/testsuite/g++.dg/template/unify10.C
    trunk/gcc/testsuite/g++.dg/template/unify11.C
    trunk/gcc/testsuite/g++.dg/template/unify6.C
    trunk/gcc/testsuite/g++.dg/template/unify7.C
    trunk/gcc/testsuite/g++.dg/template/unify9.C
    trunk/gcc/testsuite/g++.dg/template/varmod1.C
    trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash56.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/crash28.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/crash60.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit41.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit77.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/expr2.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/spec5.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/spec6.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/unify4.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/unify6.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/unify8.C
    trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb98.C

[Bug c++/48934] no rejection reason given for SFINAE

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0

--- Comment #17 from Jason Merrill <jason at gcc dot gnu.org> 2011-07-17 12:57:26 UTC ---
Fixed for 4.7.

[Bug c++/48934] no rejection reason given for SFINAE

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-07-17 16:37:48 UTC ---
this is fantastic - thanks!