Sepplesox General

Looks like there are many improvements to Sepples, but I'm not so sure that some of them are improvements. I'm going to use my post to go over some of these things that I think are downfalls.

Particularly, I'm not so sure that the inheritance specifiers are a good thing. The syntax is ugly, and like Bjarne says about the casts: Perhaps people would reconsider using them because they're so ugly.^[1] One of the major points FOR using Sepples is its inheritance system, so I'm not precisely certain what they hope to resolve with this particular addition.

The lambdas are ugly. The new string literals don't cover the primary problem with string handling: It's a pain to convert and support more than one type of string. The alternate function declaration syntax is... while necessary without creating something new entirely, I imagine that it's going to be more confusing than not, though that's probably more of a personal preference.

The rest of the features, I'm either indifferent to or like, though remanding concepts to a technical report was a bad call, imo.

^{[1] - http://www2.research.att.com/~bs/bs_faq2.html#static-cast}

Some of the new stuff in sepplesox is good. For example a range based for loop, bounds-checked std::array, etc. Things that should have been there for decades of course, but I won't complain about them. Other things are nice; for instance I never really considered the language complete without move semantics, and a few object model features are very useful (such as larger scope of pod types and unions, constructor chaining, etc). Also proper enums are great, except they left regular enums as broken instead of changing them back into their C counterparts so we could use them for bitmasks again.

Threading and a proper memory model is nice, but I don't really see it as something vendors will implement any time soon (as in not for a good 10 years). Someone will write the easy bits as an open library wrapping the native threading API, and the features that require actual compiler support will fall by the wayside, never to be used. (Example: Capturing and propagating exceptions across threads, so that accessing e.g. a future will throw the transferred exception. What the fuck?)

The lambdas are also really dumb. Why the ridiculous syntax? What's wrong with lambda or function? Also, why the fuck do I have to declare the variables I'm closing the function over to create a closure? Didn't Algol solve this 60 years ago?

Meanwhile C99 features are still outright missing. Variadic templates are nice; where are variadic macros? Variable length arrays? Where is restrict?

After that it goes past crazy and gets into the downright bizzare. The biggest WTF: User-defined non-string literals by overriding operator"" as a variadic template of char parameters. What the fucking fuck? Who thought that was a good idea? What the fuck is the problem with a regular inline constructor that takes a string. You really want to get variadic template arguments instead of a *string* just to hope the compiler optimizes it better?

Honestly, I swear Stroustrup just piles in anything anyone ever dreamt of as a feature. Forcing all vendors to implement this bullshit feature no one will ever use, and meanwhile actual useful things like garbage collection get pushed out of the standard.

And as usual, the biggest problem with C++ grows ever worse: Of course you ignore those features that are dumb, you only use the 10% that are useful to you... until you need to combine it with someone else's code and you realize, everyone has a different 10%.