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.
