On Thursday, January 24, 2013 21:38:42 Ali Çehreli wrote: > If const really requires a conversion then we have a language design > problem here.
No. const T is _not_ the same type as T, therefore assigning a T to a const T _is_ a type conversion. _Any_ time that a variable of one type is assigned to a variable of another type is a conversion regardless of the types involved. True, the bits of the object won't have changed when converting from T to const T (assuming that no alias this has been declared for the conversion anyway), but it's still a type conversion. > > So, if you have > > [...] > > These examples are great but as I said, they don't help the programmer > at function signature stage. > > immutable is easy: If I am going to need immutable data, then I make the > parameter immutable. > > By-value is also understandable: I don't care about the original. > Additionally, when a 'ref' overload exists, by-value gives me the chance > to move because only the rvalue can be bound to by-value. Pretty > indirect way of thinking but we can deal with it... > > const should be easy as well: "I am not going to modify". Just like in > C++... Unfortunately that is not the case. I don't see what could be done to make it simpler other than making it illegal to overload on constness or refness, which would cause other problems. When you're dealing with a variety of overloads, it's always going to get complicated on some level. Stuff like auto ref and inout help, but it's complicated by its very nature. Besides, the simple rule of making sure that either all of your overloads match in terms of constness or that you have overloads for both const and non-const parameters of matching refness solves the problem. And if you screw it up, it's obvious _very_ quickly, since it causes infinite recursion. - Jonathan M Davis
