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?
