Language Design: Force unsigned Bitwise Operations And Precedence of Operations

[Som1Lse]

Regarding bitwise operations:
The best solution I can think of is to introduce a new type, Bitfield that has bitwise operations defined for it, but not any arithmetic operations (so you cannot add them for example). It would be stored as a single 32-bit unsigned integer. Casting between floating points and integers is silly, and way more costly than necessary for no gain, so definitely do not do that.
Enumerations are definitely also worth considering for the added type safety.

Regarding operator precedence:
It is a historical issue (http://programmers.stackexchange.com/que...omparisons), and as a result I would not be so afraid to change it. The only place it might cause trouble is if you want to port some code from the scripting language to C++, where it might be surprising.
Regarding other operators I like the way python does comparisons (

23<x<42

in python is equivalent to

23<x && x<42

in C++), so that would be nice. I would also forbid different logical/bitwise operators operators to appear on the same level (so

a&b|c

is forbidden,

a && b || c

is also forbidden, but

a&b == 0 || c&d&e == 42

is fine).

Regarding text:
Please do NOT do that. The first one is not so bad, but the latter are particularly bad because they have different semantics to the first, despite having really similar syntax, but in general I just find that combining very different types leads to confusion in many cases and the alternative is not really that bad:

C++-Code: "text".repeat(4); // "texttexttexttext" "text".length() //4 "text"+to_string(42)

Or whatever similar syntax you prefer. Every single time I have seen some language try to infer programmer intent it has always gone wrong in one way or another.