const?? When and why? This is ugly!

[Jason House]

hasen Wrote:

> hasen wrote:
> > I haven't been following D for over a year .. now I notice there's a 
> > const!!
> > 
> > [...]
> 
> It seems the argument is centered around making "pure functions" possible.
> 
> But, surely there's a better way of doing this than borrowing const from 
> C++.
> 
> Just like import is a better approach than #include and `namespace`
> 
> Yesterday I noticed this page 
> http://www.digitalmars.com/d/2.0/const-faq.html
> which I haven't seen before posting the topic yesterday.
> 
> Argument #2 reads: "It makes for interfaces that can be relied upon, 
> which becomes increasingly important the more people that are involved 
> with the code. In other words, it scales very well."
> 
> I think this is not worth the complexity, but then again, Argument#4 
> renders #2 as insiginificant, so I won't bother too much arguing against #2.
> 
> #4 reads: "The future of programming will be multicore, multithreaded. 
> Languages that make it easy to program them will supplant languages that 
> don't."
> 
> So, this is driven by the need to popularize D as a very good tool for 
> multicore applications!
> 
> "Transitive const is key to bringing D into this paradigm."
> 
> Really? have you considered other possibilities?
> 
> How about, adding a new attribute to functions: `pure`
> 
> pure real sin( real x ) { ... }
> 
> and design the rest around this concept.
> 
> The compiler must make sure that this function is really pure:
> - native types must be passed by value, not by reference
> - doesn't accept pointers
> - <insert some condition for objects and arrays>
> 
> If these requirements aren't met, the compiler will spit some error 
> message "in function <F>: doing <X> voilates the `pure` attribute"
> 
> objects and arrays will need some special treatment or requirements in 
> order to be passed to pure functions.
> What are those requirements? I have given it a very deep thought yet(*), 
> but I'm sure this approach is better than `const`.
> 
> Also, make `string` a builtin type that's immutable (like python), and 
> discourage the use of char[] as a type for strings, (unless used to 
> implement a special string class).
> 
> The need for a special string type also stems from the fact that 
> char[a..b] slices bytes, not characters!
> 
> 
> (*) A quick idea might be:
> - For arrays, any statement of the type `a[b] = c` will be illegal 
> inside a pure function. and pure functions can only call pure functions.
> - For objects, any statement of the form `a.b = c` is illegal, and there 
> must be a way to know if a method call will change the object or not. 
> (It would be best if the compiler could detect this automatically if 
> it's possible).
> - Another approach, is to prohibit passing objects all together, and 
> introduce some new construct that's immutable (such as a tuple, again, 
> like python).
> 
> `pure` will probably have the same viral effects as `const`, in that any 
> function called from a pure function must also be pure, and this viral 
> nature will propagate to classes/objects as well.
> 
> However, the advantage is not complicating the type system more than is 
> needed.
> 
> Also, what's the deal with const pointers?? Why should `pure` function 
> be able to use pointers at all? Is there any real-life use case where a 
> pure function needs to access memory instead of some abstract concept 
> like a variable/array/tuple?
> 
> 
> If you think about it, CTFE (compile time function execution) are `pure` 
> already, and they're detected automatically by the compiler, with no 
> need for explicitly marking them as such.
> 


You're getting closer...

Your scheme uses a lot of deep copying which can kill performance. What if there was a way to skip such deep copies? Or at least force the caller to copy the data before use? How do you implement thread safe deep copies?