The standard pointer\reference notation should be depreciated. Language changes: The new way will be fashioned after templates. There is only pointer<T>, and optimization of how it is treated is left to the compiler.
Library additions: A full featured non-axiomatic set theory library. The standard operations of union, intersect, power set, are all implemented of in an unordered container, and can handle comprehensions and infinite lists. Also contains functions for Cantor's method of coding to determine countability, and checking the injectiveness and bijectiveness of mappings between two sets (possibly done at compile time). Also, that cocksucker Russell can keep his fucking types and classes, these sets can eat themselves.
Name:
Anonymous2015-02-26 7:40
Concepts were cool. Why the standards dicks removed them?
Name:
Anonymous2015-02-26 8:04
THIS IS A PROGRAMMING BBS FOR ONLY NON-SHIT LANGAUGES (C AND LISP)
My suggestion would be to make it a true superset of C and remove 90% of the garbage like multiple inheritance, overloading, exceptions, virtual functions, etc. Templates and simple classes are good, stick with that.
Name:
Anonymous2015-02-27 12:35
>>12 Rust. You're thinking of Rust. That is the name of the language you're describing.
Well, okay, except for C compatibility. The syntax is a little different and the semantics allow for a lot less undefined behavior.
>>14 Actually, it does have ABI compatibility. You can even write libs in Rust that can safely be used in a C program, which is not a feature most languages are able to have. But you can't just throw C code at a Rust compiler like you can in C++.
Name:
Anonymous2015-02-27 19:05
>>17 I assumed it would have ABI compatibility, what with going through LLVM. Source-level compatibility with any other language is a pointless endeavour anyway, if the semantics are going to be different.
But this is the essence of C. Without it, you can't have a truly fast language, because the compiler is constrained in what optimizations it's able to perform by the myopic language design.
Name:
Anonymous2015-02-27 21:43
>>19 You're right. No wonder all those C programs that never trigger UB are so slow.
Name:
Anonymous2015-02-27 23:36
Scrap it all. Standardize a Common Lisp with C syntax.
Name:
Anonymous2015-02-28 1:40
DUBS
Name:
Anonymous2015-02-28 2:05
The problem with >>19 is UB is often treated as an excuse for the optimizer to choose incorrect behaviour. Right and fast is better than wrong and faster.
Name:
Anonymous2015-02-28 2:13
>>19,20 Undefined behavior is nothing more than the exalted laziness of the language designers. It is more straightforward for both programmers and machine optimizers if don't-care cases are explicitly annotated, rather than inferred as is done in C.
Name:
Anonymous2015-02-28 3:53
>>24 They are explicitly annotated in C - that's precisely what every " ... results in undefined behavior" are.
Name:
Anonymous2015-02-28 4:04
>>25 Ahh, that reminds me of the exact thing that Sepples17 needs. Annotations! Just like Java! No more will we be confused when we override a method function from the super-super-super-super-super-class when errors are thrown without @override. Another thing could be mandatory exception handling. Don't have twenty exception handlers for everything that can go wrong with std::cout? You get that sweet, sweet five-hundred-line compile error barf that only C++ can give.
Name:
Anonymous2015-02-28 4:10
>>25 You can't see "undefined behaviour" when you look at the code only when it leads to bugs. It not obvious unless you carefully apply the standard to every line of code(i.e. hours of checks) and then you discover the compiler has a second opinion which is at odds with standard.
>>26 I suppose I should have said qualified instead of annotated to avoid triggering you. Think in terms of things like const or restrict, where the language allows you to explicitly tell the compiler to assume certain invariants that permit it to generate better code. If you omit the qualifiers, your code will still be correct.