From: Eric Friedman (ebf_at_[hidden])
Date: 2003-10-20 19:43:03
Douglas Gregor wrote:
> On Sunday 19 October 2003 08:27 pm, Eric Friedman wrote:
>>This is something I had been working on about two months ago but didn't
>>post to the sandbox until recently.
>>The basic idea is this:
>> switch_( [variant] )
>> |= case_< [pattern1] >(...)
>> |= case_< [pattern2] >(...)
>> |= default_(...) // optional catch-all
>>The switch_ will fail to compile if not every case is handled. In terms
>>of handling, the case_ constructors take typical function objects,
>>though the switch_ ignores any return values.
> I would absolutely love to see this in the library. A while back (pre-variant)
> I prototyped something similar for 'any' (with 'tuple' for product types)
> that may be of interest:
Ah, yes, I remember when you originally posted this. Anyhow, looking
back at the "requirements" you listed, I'm glad to see my implementation
currently or will soon meet many of them.
The decomposition of product types seems trickiest to me. First, I don't
see a good way of allowing the user to specify the pattern for
unpacking. Second, without such user-specified unpacking patterns, it
seems somewhat dangerous to allow the set of "unpackable" types to be
Perhaps I could abandon my current idea of using the pattern to match
the contained *type* and rather use the pattern (a la ML) to indicate
how to unpack contained product *values*. Do you see a better solution,
ideally one that allows both kinds of matching?
> The only things it did that I'd like to see in your version are:
> 1) Support for return types, as Brian already mentioned. I think this is
Agreed. I'll work on it.
> 2) I think I like putting the set of cases in brackets, but it's probably
> Ocaml-envy kicking in:
> case_<[pattern1]> (...)
> | case_<[pattern2]> (...)
> | ...
> | default_(...)
Hmm, well even so, I think it would have to look like this:
|= case_<[pattern2]> (...)
This is because I am using operator|= in order to get more efficient
left-to-right construction for the chained-case_ visitor.
> The syntactic bit is, of course, trivial and unnecessary. Pick whatever syntax
> you like.
One advantage I see to the current syntax is that it makes
commenting-out of the first "case_" very easy. I imagine this would be
useful during debugging.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk