<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.1">
</HEAD>
<BODY>
<BR>
I don't think types should consist of compound phrases. <I>viewof</I> sounds like a method name, not a part of the primitive type system. If you forget about the existing <I>const</I> in D 1, <I>const</I> beats out <I>viewof</I> on several counts:<BR>
<BR>
1. It's 1 character shorter. We call it int and not integer for a reason.<BR>
2. It's one word<BR>
3. It doesn't have a phrase which infers it's some form of translation viewof(Type) looks like you're creating a view of a type.<BR>
<BR>
That being said, I'm sort of annoyed with the fact that const(type) looks like a function. And I'm similarly annoyed with the introduction of special syntax just so we can use the same phrase to classify methods that we use to classify storage. I mean, it makes sense from the standpoint of static, but it doesn't make sense form the point that const can be a return value.<BR>
<BR>
<I>const const(Foo) foo (const Foo)</I>.<BR>
<BR>
That's just terrible.<BR>
<BR>
>From one angle, it makes sense following the form of static:<BR>
<BR>
private static int _foo;<BR>
public static int foo () { return _foo; }<BR>
<BR>
However it's not as natural, since the <I>static</I> keyword is behaving precisely the same in both of the above expressions.<BR>
<BR>
When you get to const, it stops behaving the same...that is..<BR>
<BR>
class Foo {<BR>
private const int _foo = 123;<BR>
public const int foo () { return _foo; }<BR>
}<BR>
<BR>
If I understand the D 2.0 specification as it sits now, these two <I>const</I> statements have nothing to do with each other, and that's the anomaly. In the <I>static</I> case a static method has to be static to access a static member value. But in the const case, the const method has nothing to do with the const member value. methods don't have to be const to access const member values, and vice verse. So that const only qualifies that you can call foo() in the instance of a const(Foo), which is defined as follows (assuming I understand correctly):<BR>
<BR>
const Foo foo = new Foo();<BR>
foo.foo();<BR>
<BR>
So what we've done, it seems...is taken a syntax for one behavioral class, and applied it to <I>another</I> behavioral class. And because this has been done, to retain the constivity of int the above class is invalid, and you actually must:<BR>
<BR>
class Foo {<BR>
private const int _foo = 123;<BR>
public const const(int) foo () { return _foo; }<BR>
}<BR>
<BR>
So what I'm saying I guess is, I feel like the current syntax is kind of messed up. I don't care about the keyword, but I do think const is better than viewof (although "view" might make more sense, but it really doesn't matter what it's called). <BR>
So with that being the case, what if <I>const</I> was a type annotation. That is, what if a more annotative syntax was applied to make a given identifier const:<BR>
<BR>
private int : const foo;<BR>
<BR>
Either that, or what if atleast to rid ourselves of the disparity, the const storage class syntax was removed and replaced with that which is similar to the return value... The reason I say disparity, is my understanding is that <I>const</I> on a method only verifies that no values are modified via the <I>this</I> reference...so I think that means you're completely allowed to:<BR>
<BR>
class Foo {<BR>
private int _foo = 123;<BR>
public const int foo () { return _foo; }<BR>
}<BR>
<BR>
So what if we atleast made the syntaxes consistent between storage and return values, forcibly:<BR>
<BR>
private const(int) foo; /* You have to say it's const(int).... */<BR>
public const const(int) foo () { return _foo; } /* Now atleast the syntax between the declaration of the identifier and the return value are consistent */<BR>
<BR>
Similarly, you could always bring back the C++ish method classifications (they're still around, right?)<BR>
<BR>
public const:<BR>
const int foo () { } <BR>
const int bar () { }<BR>
<BR>
I don't find them that terrible...so now we have to define <I>const</I> method types within a special area in the class...that's actually not a bad idea anyway! But I'm sure it'll get some blowback. But I'm not totally convinced this is a concept that deserves only a new definition of an old keyword. Some special syntax seem in order.<BR>
<BR>
Never forget, we introduce punctuation to provide segmentation of concept. We do the same thing in programming languages...maybe some new punctuation is needed to provide a difference between const the member class and const the storage class.<BR>
<BR>
I dunno, just some ideas. My beef with const right now isn't the concept, it's great to have transitivity in const (assuming I understand it correctly) and hell, adds a lot of power to D for multiprogramming. Honestly, I don't think nearly as much is gained by having invariants and have wonder if they provide more than an optimization opportunity for the compiler. But still, I think the syntax could use some work. It feels a little hob-gobbled. I'm sure there is a much more expressive way to do this that I haven't thought of or mentioned in this email, but I'm pretty sure whatever it is we're not doing it.<BR>
<BR>
Cheers,<BR>
Scott S. McCoy<BR>
<BR>
On Sun, 2008-03-30 at 07:58 +0100, Janice Caron wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
<TABLE CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
<BR>
</TD>
</TR>
</TABLE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="3">
<TR>
<TD>
<BR>
</TD>
</TR>
</TABLE>
<TT><FONT COLOR="#000000">Another alternative to view is viewof. As in viewof(T).</FONT></TT><BR>
<BR>
</BLOCKQUOTE>
</BODY>
</HTML>