On Thu, 23 Sep 2010 18:26:28 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Thu, 23 Sep 2010 10:05:45 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Wed, 22 Sep 2010 21:48:19 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Wed, 22 Sep 2010 13:10:36 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Wed, 22 Sep 2010 12:00:16 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
What about value types?
Value types are implicitly convertable to immutable, so they can be
strongly-pure.
No their not. Remember, arrays and other structs are value types in
the type system. Logically, they may be reference types, but as far as
their type signature goes, they are value types.
Arrays are not value types. A value type is one that contains no
references, no matter how deep. It is irrelevant if you have to spell
out the references or not.
Arrays are implemented as a struct. And as per the language spec:
(http://www.digitalmars.com/d/2.0/struct.html) all structs are value
types *to the compiler*. This doesn't mean that logically, from the
programmer's point of view, they aren't providing reference semantics.
structs can have value copy semantics. But for a struct that contains a
reference, the references have reference semantics, which makes the struct
a reference type.
Look, terms can be debated, but here is the bottom line: A struct with a
reference type inside it cannot be implicitly converted to immutable,
whereas a struct with only non-reference types in it can. The compiler
knows this, and makes its decision on what must be immutable or not based
on that knowledge. Call it whatever you want, but that's how it works
internally, and it's not hidden from the compiler.
When you say "what about value types" what do you mean? I thought you
meant types which have value copy semantics, which can only have
non-references in them.
A type that has both value copy semantics and reference semantics, I guess
you could call it a hybrid type (an array is such a type), but primarily
it is treated like a reference. If that's what you're asking about, then
those also would make a function weakly pure.
another example of something that is not a value type:
alias int * iptr;
foo(iptr p);
iptr is not a value type just because you don't see any * in the
signature.
*sigh* I explicitly referred to the type system/compiler. And to the
type system iptr is a pointer, no matter what you call it.
This is also purely a reference type. Semantically, it's exactly the same
as a pointer, except you have to refer to the member.
struct iptr
{
int *ptr;
}
You are splitting hairs here, and it's not really furthering the
discussion.
But the compiler will be able to tell. I think adding a
__traits(isStronglyPure, symbol) will be good for those rare
occasions where you really want to ensure purity.
static assert(__traits(isStronglyPure, foo));
-Steve
This would work, but it wouldn't be self-documenting, etc.
Hm... OK, well I disagree, it looks like it's documented to me. I
don't see a difference between tagging something as strongly pure and
putting in the static assert (except verbosity of course). I will note
that I think the above would be a rare situation.
To clarify, self-documenting => be able to automatically shows up in
ddoc, etc.
OK, that's a fair point, I hadn't thought of that aspect. The only
counter I have for that is, does it matter in the docs whether the
compiler will optimize via parallelizing or not? Or is it more important
just to have the compiler refuse to compile if it can't parallelize?
-Steve
