Original comment by malcolm.rowe on 25 Jan 2013 at 9:23

• Added labels: Type-Enhancement, Priority-Low, Milestone-1.2-consider

This is now a bit trickier - CompositePattern uses and implements 
IPartialPattern, which we're not exposing. We could expose a simpler version, 
of course...

Original comment by jonathan.skeet on 9 Apr 2013 at 8:15

Any thoughts about the feasibility/desirability of doing this for 1.2.0?

Original comment by malcolm.rowe on 26 Jul 2013 at 10:08

I don't think there's enough requirement for it right now - it's easy enough to 
work around, after all, and IPartialPattern makes it harder. Marking as WontFix 
for now, but could easily revisit later.

Original comment by jonathan.skeet on 26 Jul 2013 at 10:23

• Changed state: WontFix

Is this still not possible?

@lundmikkel: Not sure what you mean by "not possible" - we could expose it, but we still haven't done so yet. (If we do so, it would be for 2.0 rather than 1.3; we could potentially do it in 1.4 as well.)

Yeah, by possible I meant, if it was possible for users of the library to use it. As we talked about elsewhere, it seems that composite patterns could solve some problems, that are otherwise hard to solve. Especially when ParseResult<T> is also internal.

Yup - the ISO case is a particularly compelling one. It's niche, sure - but handy. Will need to check the API carefully, but I think I should be able to get this into 2.0.0.