Boost logo

Boost :

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-21 00:34:20

On Mon, Oct 20, 2003 at 04:03:45PM -0700, Eric Friedman wrote:
> Brian McNamara wrote:
> >Given the general form of patterns you describe below, I can't possibly
> >imagine how you determine if every case is handled, but for now I'll
> >take your word for it. :)
> OK :)

I can see it now (hindsight is 20-20). :)

> >Why ignore return values? If all cases had the same return type (or
> >returns types convertible to one fixed type), could you make the whole
> >thing an expression? Like
> >
> > int x = switch_( [variant] ) // or maybe switch_<int>( [variant] )
> > |= case_< [pattern1] >(...)
> > |= case_< [pattern2] >(...)
> > :::
> > |= default_(...) // optional catch-all
> > ;
> >
> >(The alternate syntax in the comment suggests that you pass the intended
> >return type of the whole expression as an argument to switch_, rather
> >than try to infer it from all the case arms.)
> This should be workable, and I'll look into it. On first glance, I
> prefer the second syntax (i.e., switch_<int>); otherwise I believe the
> switch would need to prefer the result type of the first case. I think
> the first syntax would also cause some difficulty with lambda expressions.

It's doable in any of these ways, but I agree that the second syntax is
preferable. I encountered the same kind of problem in FC++'s lambda
"if" expression, and ended up putting 3 solutions in the library:

   // Deduce result types of both expressions, ensure they are the same
   // type or else cause a compile-time error.
   if0[ l_cond, l_true_exp, l_false_exp ]

   // Use the type of the "true" branch as the result type; ensure that
   // the "false" branch can be coerced into this type, too.
   if1[ l_cond, l_true_exp, l_false_exp ]

   // Vice-versa (e.g. prefer the "false" branch)
   if2[ l_cond, l_true_exp, l_false_exp ]

I think for this switch construct, it makes sense to just "ask the user"
rather than trying to jump through a multiplicity of hoops.

> >Does the pattern matching only know about a fixed set of types (like
> >pair)? Or does it work on any template?
> Assuming a conformant compiler, pattern matching works on any template
> whose arity is under some implementation-defined limit (currently tied

Gotcha (I see this now, too).

As an aside, I agree with your other message in the thread, which talks
about having "|=" in front of every "case" (including the first one).

-Brian McNamara (lorgon_at_[hidden])

Boost list run by bdawes at, gregod at, cpdaniel at, john at