SuccincT Roadmap

@xlecoustillier, @gavinSteyn, @Odonno, @Opiumtm, @megafinz, I’m name checking you all here as you’ve previously contributed bug reports, suggestions or PRs and so may wish to join in this discussion. Apologies if you are no longer interested.

I’ve been very quiet regarding SuccincT now for a few months as I’ve been watching what has happened to C# with the v7.x releases and what’s planned for v8, and trying to work out what to do with SuccincT as many of those new language features impact on the reasons for this library existing in the first place.

The key features that I feel have a big impact are:

1. Readonly refs and readonly structs (C# 7.2)
2. Nullable reference types (NRT) (C# 8)
3. Recursive and parameter pattern additions to pattern matching (C# 8)

With the work around readonly structs and refs, I think it sensible to look again at the various option/union types and likely redo all of them as readonly structs.

Since the NRT will mean that reference types become non-nullable by default, the whole need for option/maybe types is called into question. If I can have string for when I definitely have a value, and string? for when I may not, what need is there for Option<string>? T? can be thought of as (an admittedly poor-man’s) maybe type.

However, it’s not exactly uncommon for null to be used as a value, so it’s quite possible that people would want to be able to do something like Option<string?>. There is no T?? (whatever that would mean), so it probably makes sense to keep an option type in SuccincT.

The new features for pattern matching in C# 8 can be experimented with today using this prototype extension for VS2017. From the experiments I’ve done, I’m not sure there will be any need for SuccincT to have its own pattern matching features when C# 8 is released. So maybe they should be removed at that stage?

So my thoughts on a road map are:

Version 4 - Work can start on this straight away

1. Remove either Option<T> or Maybe<T> and replace with a single readonly struct. I don’t mind which name it has. I’m even open to calling it Optional<T> since that name has become popular too since Java added it.
2. Replace the Union, ValueOrError and Success types with readonly structs.
3. Switch the supported framework to netstandard 2 to allow us to add @Odonno’s With features.
4. Address issues/PRs #48 (@Odonno), #49 (@gavinSteyn), #50 (@xlecoustillier) and #51 (@xlecoustillier). Care needs taking with #49 though to ensure it doesn’t cause problems with C# 8’s pattern matching later (I don’t think it will, but want to check).
5. Make use of the new Enum generic constraint to tidy up the code around the enum parser.

Version 5 - For when C# 8 is released

1. Ensure the code is compliant with NRTs,
2. Mark the Match methods as deprecated,
3. Create Rosylyn analyzer-based “code fixes” to automate rewriting SuccincT patterns into C# patterns. This is likely a lot of work, so this really is aspirational.

Version 6 - Maybe release around the time of v8.1

1. Remove SuccincT’s pattern matching support.

What are your thoughts on the above? Anyone have strong views on any of this? Or is it a case of “Whatever! You disappeared for so long, we’ve lost interest in SuccincT”? Am I being naive in thinking there’s even a need for this library after v8 is released?

Please share your thoughts and don’t spare my blushes. I’ve enjoyed working on SuccincT and I’m happy to put more work in if folk still want it. But I’m also happy to walk away and work on other things if it’s coming to the end of its useful life.

[DavidArno]

@Odonno, I avoid committing to release dates in my day job, let alone “hobby” stuff 😆

I’ve been looking into how the pattern matching features will likely work in C# 8. One of the consequences of the way they will work is that what I’d planned is unsafe as it relies on behaviour of the prototype compiler, which is not guaranteed to remain unchanged.

As a consequence, I need to put the idea of changing the option and union types into read-only structs on hold. As a result, the road map has basically changed before I even start.

At the moment, I’m looking stuff related to #38, with the idea of having TryXXX methods return Option<T> and MaybeXXX methods return Maybe<T>. Once that’s done I can then come up with a new roadmap and think about timescales.

I’m on holiday for much of the next week or so, so please don’t expect any real progress on this until early June.

[kgreen24]

@DavidArno , do you happen to have a sense of when the next release may be? I’m considering putting out a PR to make the HasValueOf I added to Unions behave polymorphically.