www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - equivariant functions

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Many functions return one of their parameters regardless of the way it 
was qualified.

char[] stripl(char[] s);
const(char)[] stripl(const(char)[] s);
invariant(char)[] stripl(invariant(char)[] s);

Stripl is not a particularly good example because it needs to work on 
wchar and dchar too, but let's ignore that aspect for now.

There's been several proposals in this group on tackling that problem.

In unrelated proposals and discussions, people mentioned the need for 
functions that return the exact type of this:

class A { A clone(); }
class B : A { B clone(); }

How can we declare A.clone such that all of its derived classes have it 
return their own type?

It took me a while to realize they are really very related. This is easy 
to figure out if you think that invariant(char)[] and char[] are 
subtypes of const(char)[]!

I discussed with Walter a variant that implements equivariant functions 
without actually adding an explicit feature to the language. Consider:

typeof(s) stripl(const(char)[] s);

This signature states that it returns the same type as an argument. I 
propose that that pattern means stripl can accept _any_ subtype of 
const(char)[] and return that exact type. Inside the function, however, 
the type of s is the type declared, thus restricting its use.

I need to convince myself that function bodies of this type can be 
reliably typechecked, but first I wanted to run it by everyone to get a 
feel of it.

Equivariant functions are not (necessarily) templates and can be used as 
virtual functions. Only one body is generated for one equivariant 
function, unless other template mechanisms are in vigor.

Here are some examples:

a) Simple equivariance

typeof(s) stripl(const(char)[] s);

b) Parameterized equivariance

typeof(s) stripl(S)(S s) if (isSomeString!S);

c) Equivariance of field:

typeof(s.ptr) getpointer(const(char)[] s);

d) Equivariance inside a class/struct declaration:

class S
{
     typeof(this) clone();
     typeof(this.field) getfield();
     int field;
}

What do you think? I'm almost afraid to post this.


Andrei
Oct 12 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 class A { A clone(); }
 class B : A { B clone(); }


...


 Here are some examples:
 
 a) Simple equivariance
 
 typeof(s) stripl(const(char)[] s);
 
 b) Parameterized equivariance
 
 typeof(s) stripl(S)(S s) if (isSomeString!S);
 
 c) Equivariance of field:
 
 typeof(s.ptr) getpointer(const(char)[] s);
 
 d) Equivariance inside a class/struct declaration:
 
 class S
 {
     typeof(this) clone();
     typeof(this.field) getfield();
     int field;
 }
 
 What do you think? I'm almost afraid to post this.
 
 
 Andrei


All your examples use typeof(something). Is the intent to make this 
example work?

 class A { A clone(); }
 class B : A { B clone(); }


I take it that this would also extend to delegates?

class A {}
class B : A {}

void foo (A delegate (A) dg) { }
B bar (B b) { }
foo (&bar);

If you require "typeof(something)", I'd never use this feature. 
Otherwise, I'd use it sometimes.
Oct 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Christopher Wright wrote:

 All your examples use typeof(something). Is the intent to make this 
 example work?
  > class A { A clone(); }
  > class B : A { B clone(); }


That example does work today. It's covariance of return values and is 
only loosely related to this topic.


 I take it that this would also extend to delegates?
 
 class A {}
 class B : A {}
 
 void foo (A delegate (A) dg) { }
 B bar (B b) { }
 foo (&bar);
 
 If you require "typeof(something)", I'd never use this feature. 
 Otherwise, I'd use it sometimes.


The example is wrong because B delegate(B) is not a supertype nor a 
subtype of A delegate(A). The proposed solution does involve writing 
typeof as an indication of the need to return the same type as the 
argument's.


Andrei
Oct 12 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 Christopher Wright wrote:

 All your examples use typeof(something). Is the intent to make this 
 example work?
  > class A { A clone(); }
  > class B : A { B clone(); }


 
 That example does work today. It's covariance of return values and is 
 only loosely related to this topic.
 

 I take it that this would also extend to delegates?

 class A {}
 class B : A {}

 void foo (A delegate (A) dg) { }
 B bar (B b) { }
 foo (&bar);

 If you require "typeof(something)", I'd never use this feature. 
 Otherwise, I'd use it sometimes.


 
 The example is wrong because B delegate(B) is not a supertype nor a 
 subtype of A delegate(A). The proposed solution does involve writing 
 typeof as an indication of the need to return the same type as the 
 argument's.
 
 
 Andrei


My mistake -- I could have written it as:
void foo (A delegate (B) dg) { }
B bar (A a) { }
foo (&bar);

No input that foo can give to the delegate cannot be given to bar, and 
no output from bar can be unacceptable.
Oct 12 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Many functions return one of their parameters regardless of the way it 
 was qualified.
 
 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);
 
 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.
 
 There's been several proposals in this group on tackling that problem.
 
 In unrelated proposals and discussions, people mentioned the need for 
 functions that return the exact type of this:
 
 class A { A clone(); }
 class B : A { B clone(); }
 
 How can we declare A.clone such that all of its derived classes have it 
 return their own type?
 
 It took me a while to realize they are really very related. This is easy 
 to figure out if you think that invariant(char)[] and char[] are 
 subtypes of const(char)[]!
 
 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:
 
 typeof(s) stripl(const(char)[] s);
 
 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, however, 
 the type of s is the type declared, thus restricting its use.
 
 I need to convince myself that function bodies of this type can be 
 reliably typechecked, but first I wanted to run it by everyone to get a 
 feel of it.
 
 Equivariant functions are not (necessarily) templates and can be used as 
 virtual functions. Only one body is generated for one equivariant 
 function, unless other template mechanisms are in vigor.
 
 Here are some examples:
 
 a) Simple equivariance
 
 typeof(s) stripl(const(char)[] s);
 
 b) Parameterized equivariance
 
 typeof(s) stripl(S)(S s) if (isSomeString!S);
 
 c) Equivariance of field:
 
 typeof(s.ptr) getpointer(const(char)[] s);
 
 d) Equivariance inside a class/struct declaration:
 
 class S
 {
     typeof(this) clone();
     typeof(this.field) getfield();
     int field;
 }
 
 What do you think? I'm almost afraid to post this.
 
 
 Andrei


Sounds good.

--

Please resolve ambiguity when s is a global variable.

string s;

// currently compiles.
typeof(s) f(int s) {
   return typeof(return).init;
}
Oct 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Many functions return one of their parameters regardless of the way it 
 was qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.

 There's been several proposals in this group on tackling that problem.

 In unrelated proposals and discussions, people mentioned the need for 
 functions that return the exact type of this:

 class A { A clone(); }
 class B : A { B clone(); }

 How can we declare A.clone such that all of its derived classes have 
 it return their own type?

 It took me a while to realize they are really very related. This is 
 easy to figure out if you think that invariant(char)[] and char[] are 
 subtypes of const(char)[]!

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the language. 
 Consider:

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, 
 however, the type of s is the type declared, thus restricting its use.

 I need to convince myself that function bodies of this type can be 
 reliably typechecked, but first I wanted to run it by everyone to get 
 a feel of it.

 Equivariant functions are not (necessarily) templates and can be used 
 as virtual functions. Only one body is generated for one equivariant 
 function, unless other template mechanisms are in vigor.

 Here are some examples:

 a) Simple equivariance

 typeof(s) stripl(const(char)[] s);

 b) Parameterized equivariance

 typeof(s) stripl(S)(S s) if (isSomeString!S);

 c) Equivariance of field:

 typeof(s.ptr) getpointer(const(char)[] s);

 d) Equivariance inside a class/struct declaration:

 class S
 {
     typeof(this) clone();
     typeof(this.field) getfield();
     int field;
 }

 What do you think? I'm almost afraid to post this.


 Andrei


 
 Sounds good.
 
 -- 
 
 Please resolve ambiguity when s is a global variable.
 
 string s;
 
 // currently compiles.
 typeof(s) f(int s) {
   return typeof(return).init;
 }


Yes, incidentally there is a bug in the current compiler (I put it 
somewhere in bugzilla a while ago) that prevents it from using parameter 
names in a typeof expression.

Andrei
Oct 12 2008
parent KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Many functions return one of their parameters regardless of the way 
 it was qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.

 There's been several proposals in this group on tackling that problem.

 In unrelated proposals and discussions, people mentioned the need for 
 functions that return the exact type of this:

 class A { A clone(); }
 class B : A { B clone(); }

 How can we declare A.clone such that all of its derived classes have 
 it return their own type?

 It took me a while to realize they are really very related. This is 
 easy to figure out if you think that invariant(char)[] and char[] are 
 subtypes of const(char)[]!

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the 
 language. Consider:

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, 
 however, the type of s is the type declared, thus restricting its use.

 I need to convince myself that function bodies of this type can be 
 reliably typechecked, but first I wanted to run it by everyone to get 
 a feel of it.

 Equivariant functions are not (necessarily) templates and can be used 
 as virtual functions. Only one body is generated for one equivariant 
 function, unless other template mechanisms are in vigor.

 Here are some examples:

 a) Simple equivariance

 typeof(s) stripl(const(char)[] s);

 b) Parameterized equivariance

 typeof(s) stripl(S)(S s) if (isSomeString!S);

 c) Equivariance of field:

 typeof(s.ptr) getpointer(const(char)[] s);

 d) Equivariance inside a class/struct declaration:

 class S
 {
     typeof(this) clone();
     typeof(this.field) getfield();
     int field;
 }

 What do you think? I'm almost afraid to post this.


 Andrei


 Sounds good.

 -- 

 Please resolve ambiguity when s is a global variable.

 string s;

 // currently compiles.
 typeof(s) f(int s) {
   return typeof(return).init;
 }


 
 Yes, incidentally there is a bug in the current compiler (I put it 
 somewhere in bugzilla a while ago) that prevents it from using parameter 
 names in a typeof expression.
 
 Andrei


Oh this is a bug? o_O I though it is expected.

Anyway this suggestion seems better than taking the type of some global 
variable.
Oct 12 2008
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 12 Oct 2008 14:34:05 -0500, Andrei Alexandrescu wrote:



 typeof(s) stripl(const(char)[] s);


 

 What do you think? I'm almost afraid to post this.


LOL. I already thought this was possible in D2. The concept sounds fine but
the "typeof(s)" part is a bit clunky. I know we have to tell the compiler
about this somehow, but maybe there is a better syntax.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Oct 12 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 12 Oct 2008 23:34:05 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Many functions return one of their parameters regardless of the way it  
 was qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 [snip]

 There's been several proposals in this group on tackling that problem.

 [snip]

 I discussed with Walter a variant that implements equivariant functions  
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I  
 propose that that pattern means stripl can accept _any_ subtype of  
 const(char)[] and return that exact type. Inside the function, however,  
 the type of s is the type declared, thus restricting its use.


Sounds more like an easter egg to me.
But that will not work, I'm afraid. Consider the following example:

char* strstr(char* str1, const(char)* str2)
{
     return str1; // it's buggy, but who cares?
}

char* s = "hello".dup.ptr;
char* p = strstr(s, "o");
p[0] = 0;

printf("%s", s); // prints 'hell'

Let's turn it into 'equivariant function':
const(char)* strstr(const(char)* str1, const(char)* str2);

Do you see the problem already?

const(char)* strstr(const(char)* str1, const(char)* str2)
{
     // which one of the two arguments is of dynamic constancy? Both?
     return str2; // <g>
}

char* s = "hello".dup.ptr;
char* p = strstr(s, "o");
p[0] = 0; // bang! access violation


The dynamic constancy attribute should be distiguishable from other  
attributes like const/invariant.

May I suggest one of my personal preference? Here it is:

sameconst(char)* strstr(sameconst(char)* str1, const(char)* str2)
{
     return str2; // compile-time error. Can't cast const(char)* to  
sameconst(char)* implicitly
}
Oct 12 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Sun, 12 Oct 2008 23:34:05 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 Let's turn it into 'equivariant function':
 const(char)* strstr(const(char)* str1, const(char)* str2);
 
 Do you see the problem already?


Yes, you didn't write it properly :o). The correct syntax is:

typeof(str1) strstr(const(char)* str1, const(char)* str2);


Andrei
Oct 12 2008
parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 13 Oct 2008 01:16:16 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 On Sun, 12 Oct 2008 23:34:05 +0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:
 Let's turn it into 'equivariant function':
 const(char)* strstr(const(char)* str1, const(char)* str2);
  Do you see the problem already?


 Yes, you didn't write it properly :o). The correct syntax is:

 typeof(str1) strstr(const(char)* str1, const(char)* str2);


 Andrei



Yeah, my bad. But still, you can't argue that typeof(str1) == typeof(str2).
Oct 12 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 May I suggest one of my personal preference? Here it is:
 
 sameconst(char)* strstr(sameconst(char)* str1, const(char)* str2)
 {
     return str2; // compile-time error. Can't cast const(char)* to 
 sameconst(char)* implicitly
 }


I prefer my solution because it's more general and addresses more issues 
than passing the qualifier out.

Andrei
Oct 12 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 13 Oct 2008 01:17:36 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 May I suggest one of my personal preference? Here it is:
  sameconst(char)* strstr(sameconst(char)* str1, const(char)* str2)
 {
     return str2; // compile-time error. Can't cast const(char)* to  
 sameconst(char)* implicitly
 }


 I prefer my solution because it's more general and addresses more issues  
 than passing the qualifier out.

 Andrei


Yes, my solution doesn't address clone() method return type, but I think  
they aren't related.

Besides, your solution can't implement the following example, so mine is  
more flexible: :)

sameconst(char)[] findPatternInS1OrS2(sameconst(char)[] s1,
	sameconst(char)[] s2, string needle);
Oct 12 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 13 Oct 2008 01:27:42 +0400, Denis Koroskin <2korden gmail.com>  
wrote:


 On Mon, 13 Oct 2008 01:17:36 +0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 May I suggest one of my personal preference? Here it is:
  sameconst(char)* strstr(sameconst(char)* str1, const(char)* str2)
 {
     return str2; // compile-time error. Can't cast const(char)* to  
 sameconst(char)* implicitly
 }


 I prefer my solution because it's more general and addresses more  
 issues than passing the qualifier out.

 Andrei


 Yes, my solution doesn't address clone() method return type, but I think  
 they aren't related.

 Besides, your solution can't implement the following example, so mine is  
 more flexible: :)

 sameconst(char)[] findPatternInS1OrS2(sameconst(char)[] s1,
 	sameconst(char)[] s2, string needle);



And also this:

class Storage
{
    sameconst(Foo) foo() sameconst(this) // const, invariant or none
    {
         return _foo;
    }

    private Foo _foo;
}

Your version?
Oct 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Mon, 13 Oct 2008 01:27:42 +0400, Denis Koroskin <2korden gmail.com> 
 wrote:
 

 On Mon, 13 Oct 2008 01:17:36 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 May I suggest one of my personal preference? Here it is:
  sameconst(char)* strstr(sameconst(char)* str1, const(char)* str2)
 {
     return str2; // compile-time error. Can't cast const(char)* to 
 sameconst(char)* implicitly
 }


 I prefer my solution because it's more general and addresses more 
 issues than passing the qualifier out.

 Andrei


 Yes, my solution doesn't address clone() method return type, but I 
 think they aren't related.

 Besides, your solution can't implement the following example, so mine 
 is more flexible: :)

 sameconst(char)[] findPatternInS1OrS2(sameconst(char)[] s1,
     sameconst(char)[] s2, string needle);


 
 
 And also this:
 
 class Storage
 {
    sameconst(Foo) foo() sameconst(this) // const, invariant or none
    {
         return _foo;
    }
 
    private Foo _foo;
 }
 
 Your version?


class Storage
{
     typeof(this._foo) foo() const { return _foo; }
}

Please note that your version is technically identical to Walter's 
suggestion:

T foo(return const T value);

meaning that whatever qualifier value had will be returned back. Your 
solution is better visually at the obvious cost of adding a keyword, and 
let me warn again that we can't afford to add one keyword for each 
problem we solve. I believe it is more fertile to align compiler's view 
of the code with programmer expectations.


Andrei
Oct 12 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Mon, 13 Oct 2008 01:17:36 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Denis Koroskin wrote:

 May I suggest one of my personal preference? Here it is:
  sameconst(char)* strstr(sameconst(char)* str1, const(char)* str2)
 {
     return str2; // compile-time error. Can't cast const(char)* to 
 sameconst(char)* implicitly
 }


 I prefer my solution because it's more general and addresses more 
 issues than passing the qualifier out.

 Andrei


 
 Yes, my solution doesn't address clone() method return type, but I think 
 they aren't related.


I just showed how they are related. You can't "think" they aren't 
related. Feel free to believe they aren't related, but that means you 
need to work around some facts.


 Besides, your solution can't implement the following example, so mine is 
 more flexible: :)
 
 sameconst(char)[] findPatternInS1OrS2(sameconst(char)[] s1,
     sameconst(char)[] s2, string needle);


This can be easily worked out with a template. There are some 
limitations of the solution I suggested. If we're able to address most 
problems, we can leave the occasional straggler to a template solution.


Andrei
Oct 12 2008
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu wrote:


 I discussed with Walter a variant that implements equivariant functions
 without actually adding an explicit feature to the language. Consider:
 
 typeof(s) stripl(const(char)[] s);


I don't like how those who are unaware of this feature will misinterpret the
meaning of the function signature.

What about use as function arguments?  I had to refactor a lot of
interface-based code because some code needed exact types and the casting
to/from interfaces was a significant performance hit.



 
 This signature states that it returns the same type as an argument. I
 propose that that pattern means stripl can accept _any_ subtype of
 const(char)[] and return that exact type. Inside the function, however,
 the type of s is the type declared, thus restricting its use.
 
 I need to convince myself that function bodies of this type can be
 reliably typechecked, but first I wanted to run it by everyone to get a
 feel of it.
 
 Equivariant functions are not (necessarily) templates and can be used as
 virtual functions. Only one body is generated for one equivariant
 function, unless other template mechanisms are in vigor.
 
 Here are some examples:
 
 a) Simple equivariance
 
 typeof(s) stripl(const(char)[] s);
 
 b) Parameterized equivariance
 
 typeof(s) stripl(S)(S s) if (isSomeString!S);
 
 c) Equivariance of field:
 
 typeof(s.ptr) getpointer(const(char)[] s);
 
 d) Equivariance inside a class/struct declaration:
 
 class S
 {
      typeof(this) clone();
      typeof(this.field) getfield();
      int field;
 }
 
 What do you think? I'm almost afraid to post this.
 
 
 Andrei
Oct 12 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Hmm. Given:

   typeof(s) foo(long s);
   auto x = foo(1);

is x going to be declared as an int? If so, is the cast of the return 
type of foo() an implicit cast, or an explicit one? If explicit, what 
about downcast conversions? For example:

   class A : B { }
   typeof(a) foo(A a) { return new A(); }
   auto x = foo(b);

If we do an explicit cast, we've got null in x. I suppose that's ok.

What about this:

    typeof(s) foo(const char[] s) { auto x = new char[3]; ...; return x; }
    invariant(char)[] t;
    auto s = foo(t);

now s will be unsafely typed as invariant(char)[]. Since const cannot be 
safely cast to invariant or mutable, we might have a serious problem.
Oct 12 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Hmm. Given:
 
   typeof(s) foo(long s);
   auto x = foo(1);
 
 is x going to be declared as an int?


int is neither a supertype or a subtype of long.

Andrei
Oct 12 2008
parent Max Samukha <samukha voliacable.com.removethis> writes:
On Sun, 12 Oct 2008 16:45:49 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


Walter Bright wrote:

 Hmm. Given:
 
   typeof(s) foo(long s);
   auto x = foo(1);
 
 is x going to be declared as an int?


int is neither a supertype or a subtype of long.

Andrei


Are typedefs subtypes of the type they are based on?

typedef int Bar;

typeof(s) foo(Bar s);
auto x = foo(1); // is x int?

What will be the type of a typeof(s) inside the function?

typeof(s) foo(const(char)[] s)
{
  alias typeof(s) T; // what type is T? 
}
Oct 12 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 If explicit, what 
 about downcast conversions? For example:
 
   class A : B { }
   typeof(a) foo(A a) { return new A(); }
   auto x = foo(b);
 
 If we do an explicit cast, we've got null in x. I suppose that's ok.


foo will not pass typechecking. Please note that we haven't discussed 
typechecking yet.


 What about this:
 
    typeof(s) foo(const char[] s) { auto x = new char[3]; ...; return x; }
    invariant(char)[] t;
    auto s = foo(t);
 
 now s will be unsafely typed as invariant(char)[]. Since const cannot be 
 safely cast to invariant or mutable, we might have a serious problem.


That function will not typecheck either. Let's defer the discussion on 
how to typecheck the function (I have a few good starters) to after we 
gauge interest in the solution.


Andrei
Oct 12 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 12 Oct 2008 23:34:05 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Many functions return one of their parameters regardless of the way it  
 was qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 Stripl is not a particularly good example because it needs to work on  
 wchar and dchar too, but let's ignore that aspect for now.

 There's been several proposals in this group on tackling that problem.

 In unrelated proposals and discussions, people mentioned the need for  
 functions that return the exact type of this:

 class A { A clone(); }
 class B : A { B clone(); }

 How can we declare A.clone such that all of its derived classes have it  
 return their own type?

 It took me a while to realize they are really very related. This is easy  
 to figure out if you think that invariant(char)[] and char[] are  
 subtypes of const(char)[]!

 I discussed with Walter a variant that implements equivariant functions  
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I  
 propose that that pattern means stripl can accept _any_ subtype of  
 const(char)[] and return that exact type. Inside the function, however,  
 the type of s is the type declared, thus restricting its use.

 I need to convince myself that function bodies of this type can be  
 reliably typechecked, but first I wanted to run it by everyone to get a  
 feel of it.

 Equivariant functions are not (necessarily) templates and can be used as  
 virtual functions. Only one body is generated for one equivariant  
 function, unless other template mechanisms are in vigor.

 Here are some examples:

 a) Simple equivariance

 typeof(s) stripl(const(char)[] s);

 b) Parameterized equivariance

 typeof(s) stripl(S)(S s) if (isSomeString!S);

 c) Equivariance of field:

 typeof(s.ptr) getpointer(const(char)[] s);

 d) Equivariance inside a class/struct declaration:

 class S
 {
      typeof(this) clone();
      typeof(this.field) getfield();
      int field;
 }

 What do you think? I'm almost afraid to post this.


 Andrei



Sorry to hit a dead horse but...

auto dg = &stripl; // what is the type of dg?
string z = dg("foo");
char[] x = dg("foo".dup);

It is great that you brought the issue to discussion, but I think this  
solution is a miss.
Oct 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 Sorry to hit a dead horse but...
 
 auto dg = &stripl; // what is the type of dg?


stripl is three overloads. You must use a precise type on the receiving 
side to get a pointer to function, as with any overloaded symbol.


 string z = dg("foo");
 char[] x = dg("foo".dup);
 
 It is great that you brought the issue to discussion, but I think this 
 solution is a miss.


I'm glad you're trying to dent it, this is the best way to find bugs in 
it. But let me note that so far you haven't gotten even near :o).


Andrei
Oct 12 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 13 Oct 2008 01:52:25 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 Sorry to hit a dead horse but...
  auto dg = &stripl; // what is the type of dg?


 stripl is three overloads. You must use a precise type on the receiving  
 side to get a pointer to function, as with any overloaded symbol.


 string z = dg("foo");
 char[] x = dg("foo".dup);
  It is great that you brought the issue to discussion, but I think this  
 solution is a miss.


 I'm glad you're trying to dent it, this is the best way to find bugs in  
 it. But let me note that so far you haven't gotten even near :o).


 Andrei


Ok, I'll try harder. Here is a common used pattern:

interface IMaybeBar
{
     Bar isBar();
     const(Bar) isBar();
     invariant(Bar) isBar();
}

class Foo : IMaybeBar
{
     Bar isBar() { return null; }
     const(Bar) isBar() const { return null; }
     invariant(Bar) isBar() invariant { return null; }
}

class Bar : Foo
{
     Bar isBar() { return this; }
     const(Bar) isBar() const { return this; }
     invariant(Bar) isBar() invariant { return this; }
}

let's change it into one.

interface IMaybeBar
{
     same(Bar) isBar() same(this); // same is shorter than sameconst and as  
descriptive as sameconst
}

class Foo
{
     same(Bar) isBar() same(this) { return null; }
}

class Bar : Foo
{
     same(Bar) isBar() same(this) { return this; }
}

Your solution? Note that it shouldn't conflict with your clone example:


 class S
 {
      typeof(this) clone();
 }
Oct 12 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 Ok, I'll try harder. Here is a common used pattern:
 
 interface IMaybeBar
 {
     Bar isBar();
     const(Bar) isBar();
     invariant(Bar) isBar();
 }


You mean:

interface IMaybeBar
{
     Bar isBar();
     const(Bar) isBar() const;
     invariant(Bar) isBar() invariant;
}


 class Foo : IMaybeBar
 {
     Bar isBar() { return null; }
     const(Bar) isBar() const { return null; }
     invariant(Bar) isBar() invariant { return null; }
 }
 
 class Bar : Foo
 {
     Bar isBar() { return this; }
     const(Bar) isBar() const { return this; }
     invariant(Bar) isBar() invariant { return this; }
 }
 
 let's change it into one.
 
 interface IMaybeBar
 {
     same(Bar) isBar() same(this); // same is shorter than sameconst and 
 as descriptive as sameconst
 }


// Yah and hijacks a short and common word.
// When will the keyword bleeding stop?


 class Foo
 {
     same(Bar) isBar() same(this) { return null; }
 }
 
 class Bar : Foo
 {
     same(Bar) isBar() same(this) { return this; }
 }
 
 Your solution? Note that it shouldn't conflict with your clone example:
 

 class S
 {
      typeof(this) clone();
 }




My solution doesn't cover this case because the functions do not return 
an incoming argument. It's a good example. I take a dent.


Andrei
Oct 12 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Mon, 13 Oct 2008 01:52:25 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Denis Koroskin wrote:

 Sorry to hit a dead horse but...
  auto dg = &stripl; // what is the type of dg?


 stripl is three overloads. You must use a precise type on the 
 receiving side to get a pointer to function, as with any overloaded 
 symbol.


 string z = dg("foo");
 char[] x = dg("foo".dup);
  It is great that you brought the issue to discussion, but I think 
 this solution is a miss.


 I'm glad you're trying to dent it, this is the best way to find bugs 
 in it. But let me note that so far you haven't gotten even near :o).


 Andrei


 
 Ok, I'll try harder. Here is a common used pattern:
 
 interface IMaybeBar
 {
     Bar isBar();
     const(Bar) isBar();
     invariant(Bar) isBar();
 }
 
 class Foo : IMaybeBar
 {
     Bar isBar() { return null; }
     const(Bar) isBar() const { return null; }
     invariant(Bar) isBar() invariant { return null; }
 }
 
 class Bar : Foo
 {
     Bar isBar() { return this; }
     const(Bar) isBar() const { return this; }
     invariant(Bar) isBar() invariant { return this; }
 }
 
 let's change it into one.
 
 interface IMaybeBar
 {
     same(Bar) isBar() same(this); // same is shorter than sameconst and 
 as descriptive as sameconst
 }
 
 class Foo
 {
     same(Bar) isBar() same(this) { return null; }
 }
 
 class Bar : Foo
 {
     same(Bar) isBar() same(this) { return this; }
 }
 
 Your solution? Note that it shouldn't conflict with your clone example:
 

 class S
 {
      typeof(this) clone();
 }




Walter found an answer last night.

interface IMaybeBar
{
     Bar isBar();
     const(Bar) isBar() const;
     invariant(Bar) isBar() invariant;
}

class Foo : IMaybeBar
{
     PassQual!(typeof(this), Bar) isBar() const { return null; }
}

class Bar : Foo
{
     typeof(this) isBar() const { return this; }
}


Andrei
Oct 13 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Mon, 13 Oct 2008 01:52:25 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 Sorry to hit a dead horse but...
  auto dg = &stripl; // what is the type of dg?


 stripl is three overloads. You must use a precise type on the 
 receiving side to get a pointer to function, as with any overloaded 
 symbol.


 string z = dg("foo");
 char[] x = dg("foo".dup);
  It is great that you brought the issue to discussion, but I think 
 this solution is a miss.


 I'm glad you're trying to dent it, this is the best way to find bugs 
 in it. But let me note that so far you haven't gotten even near :o).


 Andrei


 Ok, I'll try harder. Here is a common used pattern:

 interface IMaybeBar
 {
     Bar isBar();
     const(Bar) isBar();
     invariant(Bar) isBar();
 }

 class Foo : IMaybeBar
 {
     Bar isBar() { return null; }
     const(Bar) isBar() const { return null; }
     invariant(Bar) isBar() invariant { return null; }
 }

 class Bar : Foo
 {
     Bar isBar() { return this; }
     const(Bar) isBar() const { return this; }
     invariant(Bar) isBar() invariant { return this; }
 }

 let's change it into one.

 interface IMaybeBar
 {
     same(Bar) isBar() same(this); // same is shorter than sameconst 
 and as descriptive as sameconst
 }

 class Foo
 {
     same(Bar) isBar() same(this) { return null; }
 }

 class Bar : Foo
 {
     same(Bar) isBar() same(this) { return this; }
 }

 Your solution? Note that it shouldn't conflict with your clone example:


 class S
 {
      typeof(this) clone();
 }




 
 Walter found an answer last night.
 
 interface IMaybeBar
 {
     Bar isBar();
     const(Bar) isBar() const;
     invariant(Bar) isBar() invariant;
 }
 
 class Foo : IMaybeBar
 {
     PassQual!(typeof(this), Bar) isBar() const { return null; }
 }
 
 class Bar : Foo
 {
     typeof(this) isBar() const { return this; }
 }
 
 
 Andrei


What is PassQual!() ?_?
Oct 13 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Mon, 13 Oct 2008 01:52:25 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 Sorry to hit a dead horse but...
  auto dg = &stripl; // what is the type of dg?


 stripl is three overloads. You must use a precise type on the 
 receiving side to get a pointer to function, as with any overloaded 
 symbol.


 string z = dg("foo");
 char[] x = dg("foo".dup);
  It is great that you brought the issue to discussion, but I think 
 this solution is a miss.


 I'm glad you're trying to dent it, this is the best way to find bugs 
 in it. But let me note that so far you haven't gotten even near :o).


 Andrei


 Ok, I'll try harder. Here is a common used pattern:

 interface IMaybeBar
 {
     Bar isBar();
     const(Bar) isBar();
     invariant(Bar) isBar();
 }

 class Foo : IMaybeBar
 {
     Bar isBar() { return null; }
     const(Bar) isBar() const { return null; }
     invariant(Bar) isBar() invariant { return null; }
 }

 class Bar : Foo
 {
     Bar isBar() { return this; }
     const(Bar) isBar() const { return this; }
     invariant(Bar) isBar() invariant { return this; }
 }

 let's change it into one.

 interface IMaybeBar
 {
     same(Bar) isBar() same(this); // same is shorter than sameconst 
 and as descriptive as sameconst
 }

 class Foo
 {
     same(Bar) isBar() same(this) { return null; }
 }

 class Bar : Foo
 {
     same(Bar) isBar() same(this) { return this; }
 }

 Your solution? Note that it shouldn't conflict with your clone example:


 class S
 {
      typeof(this) clone();
 }




 Walter found an answer last night.

 interface IMaybeBar
 {
     Bar isBar();
     const(Bar) isBar() const;
     invariant(Bar) isBar() invariant;
 }

 class Foo : IMaybeBar
 {
     PassQual!(typeof(this), Bar) isBar() const { return null; }
 }

 class Bar : Foo
 {
     typeof(this) isBar() const { return this; }
 }


 Andrei


 
 What is PassQual!() ?_?


Pass the qualifiers of the first argument to the second argument. It's a 
simple template.

Andrei
Oct 13 2008
prev sibling next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 12 Oct 2008 14:34:05 -0500,
Andrei Alexandrescu wrote:

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:
 
 typeof(s) stripl(const(char)[] s);
 
 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, however, 
 the type of s is the type declared, thus restricting its use.
 
 I need to convince myself that function bodies of this type can be 
 reliably typechecked, but first I wanted to run it by everyone to get a 
 feel of it.
 
 Equivariant functions are not (necessarily) templates and can be used as 
 virtual functions. Only one body is generated for one equivariant 
 function, unless other template mechanisms are in vigor.
 
 Here are some examples:
 
 a) Simple equivariance
 
 typeof(s) stripl(const(char)[] s);
 
 b) Parameterized equivariance
 
 typeof(s) stripl(S)(S s) if (isSomeString!S);
 
 c) Equivariance of field:
 
 typeof(s.ptr) getpointer(const(char)[] s);
 
 d) Equivariance inside a class/struct declaration:
 
 class S
 {
      typeof(this) clone();
      typeof(this.field) getfield();
      int field;
 }
 
 What do you think? I'm almost afraid to post this.


I'd use it.
Oct 12 2008
prev sibling next sibling parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Can you, given an alias to a function that uses this equivariance, create a
forwarder function with the exact same behaviour? I.e. will calls to

typeof(return) identity(alias fn)(ParameterTuple!(fn) args) {
  return fn(args);
}

or similar work exactly as calls to fn, even though typeof(return) has to be
more than just a type? The parameter storage classes ref, out, lazy already
make this kind of forwarding very tricky to do right (I think you have to
escape to mixins) and I fear this'll make it even more involved.
Oct 13 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Christian Kamm wrote:

 Can you, given an alias to a function that uses this equivariance, create a
 forwarder function with the exact same behaviour? I.e. will calls to
 
 typeof(return) identity(alias fn)(ParameterTuple!(fn) args) {
   return fn(args);
 }
 
 or similar work exactly as calls to fn, even though typeof(return) has to be
 more than just a type? The parameter storage classes ref, out, lazy already
 make this kind of forwarding very tricky to do right (I think you have to
 escape to mixins) and I fear this'll make it even more involved.


I think so. Technically the problem is similar to handling an overloaded fn.

Andrei
Oct 13 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 typeof(s) stripl(const(char)[] s);
 
 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, however, 
 the type of s is the type declared, thus restricting its use.


this conflicts with current definition of typeof. Currently
 typeof(s) stripl(const(char)[] s); should be interpreted exactly as
 const(char)[] stripl(const(char)[] s);
it's unclear that typeof here gets type of actual argument rather than
parameter. Currently typeof applies to parameter.
Oct 13 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
ore-sama wrote:

 Andrei Alexandrescu Wrote:
 

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, however, 
 the type of s is the type declared, thus restricting its use.


 
 this conflicts with current definition of typeof. Currently
  typeof(s) stripl(const(char)[] s); should be interpreted exactly as
  const(char)[] stripl(const(char)[] s);
 it's unclear that typeof here gets type of actual argument rather than
parameter. Currently typeof applies to parameter.


That is correct.

Andrei
Oct 13 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 ore-sama wrote:

 Andrei Alexandrescu Wrote:
 

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, however, 
 the type of s is the type declared, thus restricting its use.


 
 this conflicts with current definition of typeof. Currently
  typeof(s) stripl(const(char)[] s); should be interpreted exactly as
  const(char)[] stripl(const(char)[] s);
 it's unclear that typeof here gets type of actual argument rather than
parameter. Currently typeof applies to parameter.


 
 That is correct.
 
 Andrei


I've never understood the reuse of keywords for new meanings. I much prefer new
keywords for new concepts.
Oct 13 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 ore-sama wrote:

 Andrei Alexandrescu Wrote:
 

 typeof(s) stripl(const(char)[] s);
 
 This signature states that it returns the same type as an
 argument. I propose that that pattern means stripl can accept
 _any_ subtype of const(char)[] and return that exact type.
 Inside the function, however, the type of s is the type
 declared, thus restricting its use.


 this conflicts with current definition of typeof. Currently 
 typeof(s) stripl(const(char)[] s); should be interpreted exactly
 as const(char)[] stripl(const(char)[] s); it's unclear that
 typeof here gets type of actual argument rather than parameter.
 Currently typeof applies to parameter.


 That is correct.
 
 Andrei


 
 I've never understood the reuse of keywords for new meanings. I much
 prefer new keywords for new concepts.


Even in natural language identical words are reused for various 
different meanings. This suggests that people would not feel comfortable 
with a very large vocabulary. The size of vocabularies varies 
dramatically, but if you look closer you'll see that languages with 
large vocabularies tend to have simpler grammars, suggesting that a 
language's overall complexity is a constant-sum game.

In programming languages growing the vocabulary indiscriminately is 
worse because it chews into the vocabulary available to user-defined 
symbols.

Also, whenever a feature is to be integrated into the language, it is 
preferable if possible to integrate it under an existing concept instead 
of "allocating" a new concept to it.


Andrei
Oct 13 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Jason House wrote:

 Andrei Alexandrescu Wrote:


 ore-sama wrote:

 Andrei Alexandrescu Wrote:


 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an
 argument. I propose that that pattern means stripl can accept
 _any_ subtype of const(char)[] and return that exact type.
 Inside the function, however, the type of s is the type
 declared, thus restricting its use.


 this conflicts with current definition of typeof. Currently 
 typeof(s) stripl(const(char)[] s); should be interpreted exactly
 as const(char)[] stripl(const(char)[] s); it's unclear that
 typeof here gets type of actual argument rather than parameter.
 Currently typeof applies to parameter.


 That is correct.

 Andrei


 I've never understood the reuse of keywords for new meanings. I much
 prefer new keywords for new concepts.


 
 Even in natural language identical words are reused for various 
 different meanings. This suggests that people would not feel comfortable 
 with a very large vocabulary. The size of vocabularies varies 
 dramatically, but if you look closer you'll see that languages with 
 large vocabularies tend to have simpler grammars, suggesting that a 
 language's overall complexity is a constant-sum game.
 
 In programming languages growing the vocabulary indiscriminately is 
 worse because it chews into the vocabulary available to user-defined 
 symbols.
 
 Also, whenever a feature is to be integrated into the language, it is 
 preferable if possible to integrate it under an existing concept instead 
 of "allocating" a new concept to it.
 
 
 Andrei


Yes. That makes foreign English learners confusing the many uses of 
prepositions.

I think a programming language should not be like a natural language, 
but it must be precise enough to reduce ambiguity as much as possible. 
Overloading keywords with entirely different meaning is no good (scope, 
static, invariant).

(I think this is OK to use typeof in this feature, since you're really 
getting a type of something.)

-

BTW, the keyword problem exists because we chose to use /[_a-z]\w*/ to 
represent identifiers, which coincide with keywords. Perl and PHP, for 
example, uses /[$ *%][_a-z]\w*/ to represent variables, so the keyword 
problem can be somewhat diminished. Of course I'm not asking you to 
adopt this, as I hate those sigils too, but I'm just saying adding 
keywords can leave user identifiers alone.
Oct 13 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Jason House wrote:

 Andrei Alexandrescu Wrote:


 ore-sama wrote:

 Andrei Alexandrescu Wrote:


 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an
 argument. I propose that that pattern means stripl can accept
 _any_ subtype of const(char)[] and return that exact type.
 Inside the function, however, the type of s is the type
 declared, thus restricting its use.


 this conflicts with current definition of typeof. Currently
 typeof(s) stripl(const(char)[] s); should be interpreted exactly
 as const(char)[] stripl(const(char)[] s); it's unclear that
 typeof here gets type of actual argument rather than parameter.
 Currently typeof applies to parameter.


 That is correct.

 Andrei


 I've never understood the reuse of keywords for new meanings. I much
 prefer new keywords for new concepts.


 Even in natural language identical words are reused for various
 different meanings. This suggests that people would not feel
 comfortable with a very large vocabulary. The size of vocabularies
 varies dramatically, but if you look closer you'll see that languages
 with large vocabularies tend to have simpler grammars, suggesting that
 a language's overall complexity is a constant-sum game.

 In programming languages growing the vocabulary indiscriminately is
 worse because it chews into the vocabulary available to user-defined
 symbols.

 Also, whenever a feature is to be integrated into the language, it is
 preferable if possible to integrate it under an existing concept
 instead of "allocating" a new concept to it.


 Andrei


 
 Yes. That makes foreign English learners confusing the many uses of
 prepositions.
 
 I think a programming language should not be like a natural language,
 but it must be precise enough to reduce ambiguity as much as possible.
 Overloading keywords with entirely different meaning is no good (scope,
 static, invariant).
 
 (I think this is OK to use typeof in this feature, since you're really
 getting a type of something.)
 
 -
 
 BTW, the keyword problem exists because we chose to use /[_a-z]\w*/ to
 represent identifiers, which coincide with keywords. Perl and PHP, for
 example, uses /[$ *%][_a-z]\w*/ to represent variables, so the keyword
 problem can be somewhat diminished. Of course I'm not asking you to
 adopt this, as I hate those sigils too, but I'm just saying adding
 keywords can leave user identifiers alone.



for example:
int  if = 5;

the   tells the parser not to treat "if" as a reserved word. I don't
know how much that feature is actually being used but having a way to
escape keywords like that also solves the problem.
Oct 13 2008
parent KennyTM~ <kennytm gmail.com> writes:
Yigal Chripun wrote:

 KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Jason House wrote:

 Andrei Alexandrescu Wrote:


 ore-sama wrote:

 Andrei Alexandrescu Wrote:


 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an
 argument. I propose that that pattern means stripl can accept
 _any_ subtype of const(char)[] and return that exact type.
 Inside the function, however, the type of s is the type
 declared, thus restricting its use.


 this conflicts with current definition of typeof. Currently
 typeof(s) stripl(const(char)[] s); should be interpreted exactly
 as const(char)[] stripl(const(char)[] s); it's unclear that
 typeof here gets type of actual argument rather than parameter.
 Currently typeof applies to parameter.


 That is correct.

 Andrei


 I've never understood the reuse of keywords for new meanings. I much
 prefer new keywords for new concepts.


 Even in natural language identical words are reused for various
 different meanings. This suggests that people would not feel
 comfortable with a very large vocabulary. The size of vocabularies
 varies dramatically, but if you look closer you'll see that languages
 with large vocabularies tend to have simpler grammars, suggesting that
 a language's overall complexity is a constant-sum game.

 In programming languages growing the vocabulary indiscriminately is
 worse because it chews into the vocabulary available to user-defined
 symbols.

 Also, whenever a feature is to be integrated into the language, it is
 preferable if possible to integrate it under an existing concept
 instead of "allocating" a new concept to it.


 Andrei


 Yes. That makes foreign English learners confusing the many uses of
 prepositions.

 I think a programming language should not be like a natural language,
 but it must be precise enough to reduce ambiguity as much as possible.
 Overloading keywords with entirely different meaning is no good (scope,
 static, invariant).

 (I think this is OK to use typeof in this feature, since you're really
 getting a type of something.)

 -

 BTW, the keyword problem exists because we chose to use /[_a-z]\w*/ to
 represent identifiers, which coincide with keywords. Perl and PHP, for
 example, uses /[$ *%][_a-z]\w*/ to represent variables, so the keyword
 problem can be somewhat diminished. Of course I'm not asking you to
 adopt this, as I hate those sigils too, but I'm just saying adding
 keywords can leave user identifiers alone.


 

 for example:
 int  if = 5;
 
 the   tells the parser not to treat "if" as a reserved word. I don't
 know how much that feature is actually being used but having a way to
 escape keywords like that also solves the problem.


int _if = 5;

The problem Andrei stated is not existing keywords chewing the 
vocabularies I believe, but *new* keywords chewing the vocabularies.

But I also think that there are some "universal keywords" that a good 
programmer should avoid using as an identifier, e.g. "define", 
"implements" etc. so you're free to use, though it could also be quite 
subjective.
Oct 13 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Jason House wrote:

 Andrei Alexandrescu Wrote:


 ore-sama wrote:

 Andrei Alexandrescu Wrote:


 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an
 argument. I propose that that pattern means stripl can accept
 _any_ subtype of const(char)[] and return that exact type.
 Inside the function, however, the type of s is the type
 declared, thus restricting its use.


 this conflicts with current definition of typeof. Currently 
 typeof(s) stripl(const(char)[] s); should be interpreted exactly
 as const(char)[] stripl(const(char)[] s); it's unclear that
 typeof here gets type of actual argument rather than parameter.
 Currently typeof applies to parameter.


 That is correct.

 Andrei


 I've never understood the reuse of keywords for new meanings. I much
 prefer new keywords for new concepts.


 
 Even in natural language identical words are reused for various 
 different meanings. This suggests that people would not feel comfortable 
 with a very large vocabulary. The size of vocabularies varies 
 dramatically, but if you look closer you'll see that languages with 
 large vocabularies tend to have simpler grammars, suggesting that a 
 language's overall complexity is a constant-sum game.
 
 In programming languages growing the vocabulary indiscriminately is 
 worse because it chews into the vocabulary available to user-defined 
 symbols.
 
 Also, whenever a feature is to be integrated into the language, it is 
 preferable if possible to integrate it under an existing concept instead 
 of "allocating" a new concept to it.
 
 
 Andrei


Just read this paper by Herb Sutter last night:

http://www.gotw.ca/publications/C++CLIRationale.pdf

In particular, the Bjarne Stroustrup quote is quite poignant:

""
My experience is that people are addicted to keywords for introducing 
concepts to the point where a concept  that doesnt  have its own 
keyword is surprisingly  hard to  teach. This effect is more important 
and deep-rooted  than  peoples  vocally expressed  dislike for new 
keywords.  Given a choice and time to consider, people invariably choose 
the new keyword over a clever workaround.
        B. Stroustrup (D&E, p. 119)
""

And Herb himself:

""
When a language feature is necessary, programmers strongly
prefer keywords. Normally, all C++ keywords  are also re-
served words, and taking a new one would break code that
is already using that word as an identifier (e.g., as a type or
variable name).

C++/CLI avoids adding reserved words so as to preserve the
goal of having pure extensions, but it also recognizes that
programmers expect keywords. C++/CLI balances  these re-
quirements by adding keywords where most are not reserved
words and so do not conflict with user identifiers.
""
Oct 13 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 Just read this paper by Herb Sutter last night:
 
 http://www.gotw.ca/publications/C++CLIRationale.pdf
 
 In particular, the Bjarne Stroustrup quote is quite poignant:
 
 ""
 My experience is that people are addicted to keywords for introducing 
 concepts to the point where a concept  that doesnt  have its own 
 keyword is surprisingly  hard to  teach. This effect is more important 
 and deep-rooted  than  peoples  vocally expressed  dislike for new 
 keywords.  Given a choice and time to consider, people invariably choose 
 the new keyword over a clever workaround.
        B. Stroustrup (D&E, p. 119)
 ""


I agree. I'd also add that that could backfire as well. "class" being 
essentially the same deal as "struct" with a different hat has wasted a 
perfect opportunity to create a really useful distinct concept. Right 
now it's no more than a source of embarrassment. "typename" is a shame 
begotten by another shame, the angle brackets. "explicit" is an 
expensive fix for a minor problem, bringing along with it new oddities 
and corner-case behaviors that had to be defined.


 And Herb himself:
 
 ""
 When a language feature is necessary, programmers strongly
 prefer keywords. Normally, all C++ keywords  are also re-
 served words, and taking a new one would break code that
 is already using that word as an identifier (e.g., as a type or
 variable name).
 
 C++/CLI avoids adding reserved words so as to preserve the
 goal of having pure extensions, but it also recognizes that
 programmers expect keywords. C++/CLI balances  these re-
 quirements by adding keywords where most are not reserved
 words and so do not conflict with user identifiers.
 ""


I agree. When considering keyword addition, I think we all should think 
more about adding contextual keywords, which in the grand D tradition 
are usually defined as keyword(contextual_keyword).


Andrei
Oct 13 2008
next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
Andrei Alexandrescu wrote:

 I agree. When considering keyword addition, I think we all should think 
 more about adding contextual keywords, which in the grand D tradition 
 are usually defined as keyword(contextual_keyword).


Is there some reason why most languages don't use a reserved symbol for 
keywords, like prefixing them with $ or %?  Every language runs into the 
problem of wanting to add new keywords later on -- why don't new 
languages avoid this old problem?

-Jeff
Oct 13 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 14, 2008 at 12:02 PM, Jeff Nowakowski <jeff dilacero.org> wrote:

 Andrei Alexandrescu wrote:

 I agree. When considering keyword addition, I think we all should think
 more about adding contextual keywords, which in the grand D tradition are
 usually defined as keyword(contextual_keyword).


 Is there some reason why most languages don't use a reserved symbol for
 keywords, like prefixing them with $ or %?  Every language runs into the
 problem of wanting to add new keywords later on -- why don't new languages
 avoid this old problem?


As someone mentioned, Perl uses the opposite.  User identifiers are
prefixed with $ or  , keywords are bare.

I think the reason it's not used more commonly is just that the code
starts to look like line noise.

I've not seen a language where keywords are prefixed, but now that you
mention it, it does kinda make sense.  You only expect to have a few
dozen keywords, but the number of variables used in any given program
will be much much greater.  So if you're going to push one or the
other into a separate namespace, it seems more logical to do it to the
keywords, not the identifiers.

I think in Perl's case, Larry Wall thought that making the distinction
between scalars ($var) and arrays ( var) would be useful information
to always have right in your face like.

--bb
Oct 13 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:

 I've not seen a language where keywords are prefixed, but now that you
 mention it, it does kinda make sense.  You only expect to have a few
 dozen keywords, but the number of variables used in any given program
 will be much much greater.  So if you're going to push one or the
 other into a separate namespace, it seems more logical to do it to the
 keywords, not the identifiers.




My preference in D would have been for compile-time keywords to use that 
same convention, rather than all being prefixed with the word "static".

--benji
Oct 13 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 14, 2008 at 1:54 PM, Benji Smith <dlanguage benjismith.net> wrote:

 Bill Baxter wrote:

 I've not seen a language where keywords are prefixed, but now that you
 mention it, it does kinda make sense.  You only expect to have a few
 dozen keywords, but the number of variables used in any given program
 will be much much greater.  So if you're going to push one or the
 other into a separate namespace, it seems more logical to do it to the
 keywords, not the identifiers.





Good point.  A sub-language grafted on top of another language...

Text markup languages like HTML/XML etc are like that too, now that I
think of it.  The keywords aren't prefixed, but they are syntactically
separated.  Doxygen/JavaDoc/DDoc are other examples.  Those  param
type keywords are all prefixed.  LaTeX is like that too.


 My preference in D would have been for compile-time keywords to use that
 same convention, rather than all being prefixed with the word "static".



under-performers.  There was a discussion about reclaiming it maybe
over a year ago.  I think it involved Andrei, too -- in his first
stint on the NG, before his extended leave.

--bb
Oct 13 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 I agree. When considering keyword addition, I think we all should think 
 more about adding contextual keywords, which in the grand D tradition 
 are usually defined as keyword(contextual_keyword).


C++/CLI adds them in quite a few places as long as they could not be 
misinterpreted as identifiers, and still allows them as identifiers in 
places where identifiers would be expected. Of course, it makes writing 
a parser a bit harder (but the technique itself doesn't require semantic 
analysis, so D could use this while maintaining an unambiguous grammar).

For example, the "in" keyword can never occur in an identifier position, 
so it's treated as an identifier if it's in one, and treated as an 
operator if it's seen in a "for each" loop (another cool syntax in the 
language to sneak in a keyword -- note the space).
Oct 14 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 Even in natural language identical words are reused for various 
 different meanings. This suggests that people would not feel comfortable 
 with a very large vocabulary. The size of vocabularies varies 
 dramatically, but if you look closer you'll see that languages with 
 large vocabularies tend to have simpler grammars, suggesting that a 
 language's overall complexity is a constant-sum game.


When you try to use principles from natural languages in a programming 
language, you might end up with Perl. For all of our sakes, be careful.

For that matter, what about adding a few synonyms to D? There's always 
== versus is for primitive value types....
Oct 13 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:

 Jason House wrote:

 Andrei Alexandrescu Wrote:


 ore-sama wrote:

 Andrei Alexandrescu Wrote:


 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an
 argument. I propose that that pattern means stripl can accept
 _any_ subtype of const(char)[] and return that exact type.
 Inside the function, however, the type of s is the type
 declared, thus restricting its use.


 this conflicts with current definition of typeof. Currently 
 typeof(s) stripl(const(char)[] s); should be interpreted exactly
 as const(char)[] stripl(const(char)[] s); it's unclear that
 typeof here gets type of actual argument rather than parameter.
 Currently typeof applies to parameter.


 That is correct.

 Andrei


 I've never understood the reuse of keywords for new meanings. I much
 prefer new keywords for new concepts.


 
 Even in natural language identical words are reused for various 
 different meanings. This suggests that people would not feel comfortable 
 with a very large vocabulary. The size of vocabularies varies 
 dramatically, but if you look closer you'll see that languages with 
 large vocabularies tend to have simpler grammars, suggesting that a 
 language's overall complexity is a constant-sum game.
 
 In programming languages growing the vocabulary indiscriminately is 
 worse because it chews into the vocabulary available to user-defined 
 symbols.
 
 Also, whenever a feature is to be integrated into the language, it is 
 preferable if possible to integrate it under an existing concept instead 
 of "allocating" a new concept to it.
 
 
 Andrei


But this is somewhat unprecedented in D. In other situations of keyword 
recycling, the new keyword meaning was usually added in a new context 
where the previous use of the same keyword was not valid and was totally 
unrelated. (ie, 'invariant' for example).

But this makes new use of typeof in a situation which is very similar to 
the previous use, but not consistent or orthogonal with such previous 
use (ie, the behavior is quite different). The only thing that 
distinguishes the uses is whether the typeof expression references a 
parameter defined ahead, instead of something which is in scope. This 
seems confusing to look for.
In fact, one could argue that typeof (the normal one) used in a function 
return type should be able to see the function's parameter, even though 
syntactically it appears before (semantically it makes more sense to 
come afterwards).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2008
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-12 15:34:05 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Many functions return one of their parameters regardless of the way it 
 was qualified.
 
 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);
 
 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.
 
 There's been several proposals in this group on tackling that problem.


I'm not sure why one would one add another syntax feature for this. I 
mean: we have templates which are capable of this. Sure, templates are 
instanciated only when needed and that's not what we want, but I think 
we'd better reuse the syntax we have, adding a modifier and if 
necessary for forcing one instanciation at the definition site when 
possible.

I'm not sure if this is valid in D2 (I don't have a D2 compiler in 
front of me right now), but let's say that this makes C any subtype of 
const(char):

	C strip1(C : const(char))(C[] s);

This template does what you want, except that it's instanciated only at 
the call site, making it unusable in some situations. What we need is 

one instanciation dealing with multiple parametrized types. So let's 
extend the template syntax a little:

	C strip1(equivariant C : const(char))(C[] s);

Hum, what did that change? Well, the new "equivariant" keyword I added 
imposes new restrictions to the template argument, such as you cannot 
know the exact type beyond the type restriction in the parameter 
definition. These restrictions are designed to enable only one 
instanciation of the template to cover them all. For instance:

	C strip1(equivariant C : const(char))(C[] s)
	{
		C[] s1 = s; // okay, s1 is of the same type.
		C[] s2 = "abc"; // error, "abc" is invariant(char)[],
		                // incompatible with base type const(char)[]
		C[] s2 = new C[5]; // can allocate since we know we deal with "char",
		                   // whatever constness it has, it'll always be of 
the same size.
		return s; // okay, same type.
	}

Reusing the template syntax would avoid adding yet another different 
but similar syntax for generic functions. Perhaps you find the template 
syntax overly verbose for this (I do), but then I'd say it's the 
template syntax that ought to be rethought instead reinventing it in 
another more limited form for equivariant functions.

(Of course we could start from an equivalent function syntax and then 
extend it to templates later, so I'm not really against what you're 
exposing here. I only wish we can reach some syntax consistency in the 
end.)

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 13 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:

 On 2008-10-12 15:34:05 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 

 Many functions return one of their parameters regardless of the way it 
 was qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.

 There's been several proposals in this group on tackling that problem.


 
 I'm not sure why one would one add another syntax feature for this. I 
 mean: we have templates which are capable of this. Sure, templates are 
 instanciated only when needed and that's not what we want, but I think 
 we'd better reuse the syntax we have, adding a modifier and if necessary 
 for forcing one instanciation at the definition site when possible.


That's a good point.


 I'm not sure if this is valid in D2 (I don't have a D2 compiler in front 
 of me right now), but let's say that this makes C any subtype of 
 const(char):
 
     C strip1(C : const(char))(C[] s);


High time to change fonts in your newsreader: it's stripL, not 
stripOne... :o) Here's a better way to write that template:

S stripl(S)(S s) if (is(S : const char[]));

meaning S is a subtype of const char[].


 This template does what you want, except that it's instanciated only at 
 the call site, making it unusable in some situations. What we need is to 

 instanciation dealing with multiple parametrized types. So let's extend 
 the template syntax a little:
 
     C strip1(equivariant C : const(char))(C[] s);
 
 Hum, what did that change? Well, the new "equivariant" keyword I added 
 imposes new restrictions to the template argument, such as you cannot 
 know the exact type beyond the type restriction in the parameter 
 definition.


I think this could work, but then if you take the hit of a new keyword, 
maybe Denis' solution works even better. It's less verbose and easier to 
understand.


Andrei
Oct 13 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Michel Fortin Wrote:


 On 2008-10-12 15:34:05 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 

 Many functions return one of their parameters regardless of the way it 
 was qualified.
 
 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);
 
 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.
 
 There's been several proposals in this group on tackling that problem.


 
 I'm not sure why one would one add another syntax feature for this. I 
 mean: we have templates which are capable of this. Sure, templates are 
 instanciated only when needed and that's not what we want, but I think 
 we'd better reuse the syntax we have, adding a modifier and if 
 necessary for forcing one instanciation at the definition site when 
 possible.


Templates are non-virtual right now







 
 I'm not sure if this is valid in D2 (I don't have a D2 compiler in 
 front of me right now), but let's say that this makes C any subtype of 
 const(char):
 
 	C strip1(C : const(char))(C[] s);
 
 This template does what you want, except that it's instanciated only at 
 the call site, making it unusable in some situations. What we need is 

 one instanciation dealing with multiple parametrized types. So let's 
 extend the template syntax a little:
 
 	C strip1(equivariant C : const(char))(C[] s);
 
 Hum, what did that change? Well, the new "equivariant" keyword I added 
 imposes new restrictions to the template argument, such as you cannot 
 know the exact type beyond the type restriction in the parameter 
 definition. These restrictions are designed to enable only one 
 instanciation of the template to cover them all. For instance:
 
 	C strip1(equivariant C : const(char))(C[] s)
 	{
 		C[] s1 = s; // okay, s1 is of the same type.
 		C[] s2 = "abc"; // error, "abc" is invariant(char)[],
 		                // incompatible with base type const(char)[]
 		C[] s2 = new C[5]; // can allocate since we know we deal with "char",
 		                   // whatever constness it has, it'll always be of 
 the same size.
 		return s; // okay, same type.
 	}
 
 Reusing the template syntax would avoid adding yet another different 
 but similar syntax for generic functions. Perhaps you find the template 
 syntax overly verbose for this (I do), but then I'd say it's the 
 template syntax that ought to be rethought instead reinventing it in 
 another more limited form for equivariant functions.
 
 (Of course we could start from an equivalent function syntax and then 
 extend it to templates later, so I'm not really against what you're 
 exposing here. I only wish we can reach some syntax consistency in the 
 end.)
 
 -- 
 Michel Fortin
 michel.fortin michelf.com
 http://michelf.com/
Oct 13 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Jason House wrote:

 Templates are non-virtual right now


That could be changed, but it would require a lot of bookkeeping in 
temporary files (and not object files). And it would interfere with 
precompiled libraries.

Once D gets decent runtime reflection, I'd like to get generics that 
would pretty much just hide a bunch of casts and reflection calls:

generic (T : class) void foo (T thing)
{
	int i = thing.someMethod();
	thing.otherMethod (10, true, new Object());
}

transforms to:
void foo (ClassInfo info, Object thing)
{
	int i = *cast(int*)info.getMethod ("someMethod").invoke!()(thing);
	info.getMethod ("otherMethod").invoke!(uint, bool, Object)(thing, 10, 
true, new Object());
}

But that's probably a bit much to ask.
Oct 13 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Christopher Wright wrote:


 Jason House wrote:

 Templates are non-virtual right now


 
 That could be changed, but it would require a lot of bookkeeping in
 temporary files (and not object files). And it would interfere with
 precompiled libraries.


If a template's arguments can be defined a prior, adding the functions to
the vtable is easy.  That middle ground may be useful, but wouldn't work
for everything.
Oct 13 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Jason House wrote:

 Christopher Wright wrote:
 

 Jason House wrote:

 Templates are non-virtual right now


 That could be changed, but it would require a lot of bookkeeping in
 temporary files (and not object files). And it would interfere with
 precompiled libraries.


 
 If a template's arguments can be defined a prior, adding the functions to
 the vtable is easy.  That middle ground may be useful, but wouldn't work
 for everything.


If the range of possible arguments is not extensible, yes. You can get 
this by deferring the creation of the vtbl until after all templates 
have been instantiated. Or you can get it by analyzing the template 
parameters, but that's extremely expensive. Maybe if the parameter is an 
enum value, or based on constness of a particular type, but that's about it.

That would take a lot of development time. I hope that Walter doesn't 
choose to pursue this in the near future.
Oct 13 2008
prev sibling next sibling parent reply Aarti_pl <aarti interia.pl> writes:
I don't want to push once again my solution for templates from "Uniform 
syntax" thread, but it seems that my solution would work also in this 
case as it is another type of pattern matching.

My comments inlined.


Andrei Alexandrescu pisze:

 Many functions return one of their parameters regardless of the way it 
 was qualified.
 
 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);
 
 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.
 
 There's been several proposals in this group on tackling that problem.


Q(char)[] stripl(Q : Q(char)[] s);

It is not template, so it should be putted into "runtime parenthesis". 
In first case (function taking char[]) Q will be evaluated to nothing 
and will be skipped.


 In unrelated proposals and discussions, people mentioned the need for 
 functions that return the exact type of this:
 
 class A { A clone(); }
 class B : A { B clone(); }
 
 How can we declare A.clone such that all of its derived classes have it 
 return their own type?


In this case I would just use typeof(this)

class A { typeof(this) clone(); }
class B : A { typeof(this) clone(); }

I don't see a reason why it should be same as in above case.


 It took me a while to realize they are really very related. This is easy 
 to figure out if you think that invariant(char)[] and char[] are 
 subtypes of const(char)[]!
 
 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:
 
 typeof(s) stripl(const(char)[] s);


This solution seems to me quite unclear. I would prefer if something 
better would be invented.


 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, however, 
 the type of s is the type declared, thus restricting its use.
 
 I need to convince myself that function bodies of this type can be 
 reliably typechecked, but first I wanted to run it by everyone to get a 
 feel of it.
 
 Equivariant functions are not (necessarily) templates and can be used as 
 virtual functions. Only one body is generated for one equivariant 
 function, unless other template mechanisms are in vigor.
 
 Here are some examples:
 
 a) Simple equivariance
 
 typeof(s) stripl(const(char)[] s);


Q(char)[] stripl(Q : Q(char)[] s);

or

typeof(s) stripl(Q : Q(char)[] s);

No problems here.


 b) Parameterized equivariance
 
 typeof(s) stripl(S)(S s) if (isSomeString!S);


Q(S) stripl(S)(Q : Q(S) if(isSomeString!(S)) s);

or

Q(S) stripl(S)(Q : Q(S) s) if(isSomeString!(S));

or

typeof(s) stripl(S)(Q : Q(S) s) if(isSomeString!(S));

(Sorry, I don't accommodate syntax without parenthesis for one parameter 
templates :-[)


 
 c) Equivariance of field:
 
 typeof(s.ptr) getpointer(const(char)[] s);


typeof(s.ptr) getpointer(Q : Q(char)[] s);

In this case Q doesn't matter, so it is not used in result type. typeof 
is still useful.


 d) Equivariance inside a class/struct declaration:
 
 class S
 {
     typeof(this) clone();
     typeof(this.field) getfield();
     int field;
 }
 


Looks ok.



 What do you think? I'm almost afraid to post this.
 Andrei


IMHO your solution is almost perfect. I was lacking just a clear 
definition what can be changed by user. My version is maybe longer, but 
also more clear about intents.

IMHO two versions should be allowed:

Q(char)[] stripl(Q : Q(char)[] s); and
typeof(s) stripl(Q : Q(char)[] s);

Best Regards
Marcin Kuszczak
(aarti_pl)
Oct 13 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Aarti_pl wrote:

 I don't want to push once again my solution for templates from "Uniform 
 syntax" thread, but it seems that my solution would work also in this 
 case as it is another type of pattern matching.
 
 My comments inlined.
 
 
 Andrei Alexandrescu pisze:

 Many functions return one of their parameters regardless of the way it 
 was qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.

 There's been several proposals in this group on tackling that problem.


 
 Q(char)[] stripl(Q : Q(char)[] s);


It was my first choice. Walter would rather avoid it for implementation 
difficulty reasons.


 It is not template, so it should be putted into "runtime parenthesis". 
 In first case (function taking char[]) Q will be evaluated to nothing 
 and will be skipped.


And that's part of the difficulty: there is one more type of alias, and 
now it could even expand to nothing.


 In unrelated proposals and discussions, people mentioned the need for 
 functions that return the exact type of this:

 class A { A clone(); }
 class B : A { B clone(); }

 How can we declare A.clone such that all of its derived classes have 
 it return their own type?


 
 In this case I would just use typeof(this)
 
 class A { typeof(this) clone(); }
 class B : A { typeof(this) clone(); }
 
 I don't see a reason why it should be same as in above case.


Because you don't want B's implementor to implement clone to return an 
A. That would be a mistake.


 It took me a while to realize they are really very related. This is 
 easy to figure out if you think that invariant(char)[] and char[] are 
 subtypes of const(char)[]!

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the language. 
 Consider:

 typeof(s) stripl(const(char)[] s);


 
 This solution seems to me quite unclear. I would prefer if something 
 better would be invented.


Yah me too.


Andrei
Oct 13 2008
parent Aarti_pl <aarti interia.pl> writes:
Andrei Alexandrescu pisze:


 In unrelated proposals and discussions, people mentioned the need for 
 functions that return the exact type of this:

 class A { A clone(); }
 class B : A { B clone(); }

 How can we declare A.clone such that all of its derived classes have 
 it return their own type?


 In this case I would just use typeof(this)

 class A { typeof(this) clone(); }
 class B : A { typeof(this) clone(); }

 I don't see a reason why it should be same as in above case.


 
 Because you don't want B's implementor to implement clone to return an 
 A. That would be a mistake.
 


IMHO it is much more consistent than current situation. When you write 
typeof(this) in class B it should mean B not A (currently when 
overriding A function with above signature you will get result of type A 
), because "this" for B objects is clearly of type B. Additionally such 
a syntax shows that function participate in overriding, as the result 
type is same (like in common cases).

BTW. I hope that Walter will reconsider more complicated solutions (also 
my proposal :-) ) because compiler "facade" to user is very important. 
This is the syntax, which makes working with language pleasure or 
difficult. It might be worthy to put more time into implementation, but 
get more flexible and clean solution.

BR
Marcin Kuszczak
(aarti_pl)
Oct 13 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 Your solution is better visually


I'll appreciate a visually better, easily readable language. We already have
powerful language with horrible syntax, we don't need one more. :)
Oct 13 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
ore-sama wrote:

 Andrei Alexandrescu Wrote:
 

 Your solution is better visually


 
 I'll appreciate a visually better, easily readable language. We
 already have powerful language with horrible syntax, we don't need
 one more. :)


I hear you! There are quite a few things to keep in the air at once.

Andrei
Oct 13 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'm glad there's interest in equivariant functions. Let me share below 
how I think they can be properly typechecked.

The general signature of an equivariant function is:

typeof(expression_involving(pk)) fun(T1 p1, ..., Tk pk, ..., Tn pn);

The actual notation does not matter for the purpose of typechecking. 
What the notation means is that fun will accept a subtype of Tk in 
position pk, call it Uk, and will return type Uk. Of course, for that 
magic to happen there are a few restrictions that must be met.

The simplest way to typecheck fun is by substituting Tk with a typedef 
for it:

typedef Tk __Surrogate;
typeof(expression_involving(__Surrogate.init))
fun(T1 p1, ..., __Surrogate pk, ..., Tn pn)
{
    ... typecheck me ...
}

The typedef was Walter's idea; my idea involved a synthetic subtype. I 
think the typedef has a lot of appeal. This is because the typedef of Tk 
is almost like a subtype of Tk: it has Tk's layout trivially prefix it, 
converts to Tk implicitly, yet it is a distinct type.

Let's see this typechecking at work:

1. Accessing a field:

typeof(s.ptr) at(const char[] s, uint i) { return s.ptr + i; }

Typecheck with a typedef for const char[], yielding:

typedef const(char[]) __Surrogate;
typeof(__Surrogate.init.ptr) at(__Surrogate s, uint i)
{ return s.ptr + i; }

Pass.

2. Returning (part of) an argument:

typeof(s) stripl(const(char)[] s)
{
     uint i;
     ...
     return s[i .. $];
}

Typecheck like this:

typedef const(char)[] __Surrogate;
__Surrogate stripl(__Surrogate s)
{
     uint i;
     ...
     return s[i .. $];
}

Fail. I think that reveals a bug in the compiler. A slice of a typedef'd 
array should return the same type as the array itself. I'll file a bug.

3. Walter's example:

class Base {}
class Derived : Base {}

typeof(a) foo(Base a) { return new Base; }

Typecheck like this:

typedef Base __Surrogate;
__Surrogate foo(__Surrogate a)
{
     return new Base;
}

Fail, as it should.


Come at it with all you've got.

Andrei
Oct 13 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 I'm glad there's interest in equivariant functions. Let me share below how 
 I think they can be properly typechecked.

 The general signature of an equivariant function is:

 typeof(expression_involving(pk)) fun(T1 p1, ..., Tk pk, ..., Tn pn);

 The actual notation does not matter for the purpose of typechecking. What 
 the notation means is that fun will accept a subtype of Tk in position pk, 
 call it Uk, and will return type Uk. Of course, for that magic to happen 
 there are a few restrictions that must be met.

 The simplest way to typecheck fun is by substituting Tk with a typedef for 
 it:

 typedef Tk __Surrogate;
 typeof(expression_involving(__Surrogate.init))
 fun(T1 p1, ..., __Surrogate pk, ..., Tn pn)
 {
    ... typecheck me ...
 }

 The typedef was Walter's idea; my idea involved a synthetic subtype. I 
 think the typedef has a lot of appeal. This is because the typedef of Tk 
 is almost like a subtype of Tk: it has Tk's layout trivially prefix it, 
 converts to Tk implicitly, yet it is a distinct type.

 Let's see this typechecking at work:

 1. Accessing a field:

 typeof(s.ptr) at(const char[] s, uint i) { return s.ptr + i; }

 Typecheck with a typedef for const char[], yielding:

 typedef const(char[]) __Surrogate;
 typeof(__Surrogate.init.ptr) at(__Surrogate s, uint i)
 { return s.ptr + i; }

 Pass.

 2. Returning (part of) an argument:

 typeof(s) stripl(const(char)[] s)
 {
     uint i;
     ...
     return s[i .. $];
 }

 Typecheck like this:

 typedef const(char)[] __Surrogate;
 __Surrogate stripl(__Surrogate s)
 {
     uint i;
     ...
     return s[i .. $];
 }

 Fail. I think that reveals a bug in the compiler. A slice of a typedef'd 
 array should return the same type as the array itself. I'll file a bug.

 3. Walter's example:

 class Base {}
 class Derived : Base {}

 typeof(a) foo(Base a) { return new Base; }

 Typecheck like this:

 typedef Base __Surrogate;
 __Surrogate foo(__Surrogate a)
 {
     return new Base;
 }

 Fail, as it should.


 Come at it with all you've got.


I think there is a problem with a simple typedef.  The problem is that all 
the fields and functions do not have an equivalent typedef, only the outer 
type has a typedef.  What you need is a 'deep' typedef, or one that typedefs 
all the contained types for all the fields/functions to ensure that a piece 
of another argument that is not protected by the typeof() construct is not 
returned.  So what we really need is a type modifier, like const.

Here is an example:

typedef const(char[]) __Surrogate;
typeof(__Surrogate.init.ptr) foo(__Surrogate s, uint i, const(char)[] s2)
{
    return s2.ptr + i;
}

In your proposed notation, this would look like:

typeof(s.ptr) foo(const(char)[] s, uint i, const(char)[] s2)

This should fail to compile, but it doesn't (tested with 2.019).  You can 
cause problems like this:

char[] test = "test".dup;
char *testptr = foo(test, 0, "TEST");

Now testptr points to the beginning of the invariant string "TEST".

But your usage of typedef is very good!  I never thought of it that way when 
designing the scoped const proposal.

BTW, I didn't say it in my other reply, but I would definitely use something 
like this.

-Steve
Oct 14 2008
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu wrote:

 3. Walter's example:
 
 class Base {}
 class Derived : Base {}
 
 typeof(a) foo(Base a) { return new Base; }
 
 Typecheck like this:
 
 typedef Base __Surrogate;
 __Surrogate foo(__Surrogate a)
 {
     return new Base;
 }
 
 Fail, as it should.
 
 
 Come at it with all you've got.


What does 'return new typeof(a);' do? :)
Oct 15 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 Denis Koroskin wrote:

 class Storage
 {
    sameconst(Foo) foo() sameconst(this) // const, invariant or none
    {
         return _foo;
    }
 
    private Foo _foo;
 }
 
 Your version?


 
 class Storage
 {
      typeof(this._foo) foo() const { return _foo; }
 }
 


In this example signature (interface) explicitly depends on private field
(implementation). I just tried to imagine how to document its return type.
Oct 13 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
ore-sama wrote:

 Andrei Alexandrescu Wrote:
 

 Denis Koroskin wrote:

 class Storage { sameconst(Foo) foo() sameconst(this) // const,
 invariant or none { return _foo; }
 
 private Foo _foo; }
 
 Your version?


 class Storage { typeof(this._foo) foo() const { return _foo; } }
 


 
 In this example signature (interface) explicitly depends on private
 field (implementation). I just tried to imagine how to document its
 return type.


That's a good point.

Andrei
Oct 13 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Many functions return one of their parameters regardless of the way it was 
 qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 Stripl is not a particularly good example because it needs to work on 
 wchar and dchar too, but let's ignore that aspect for now.

 There's been several proposals in this group on tackling that problem.

 In unrelated proposals and discussions, people mentioned the need for 
 functions that return the exact type of this:

 class A { A clone(); }
 class B : A { B clone(); }

 How can we declare A.clone such that all of its derived classes have it 
 return their own type?

 It took me a while to realize they are really very related. This is easy 
 to figure out if you think that invariant(char)[] and char[] are subtypes 
 of const(char)[]!

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I 
 propose that that pattern means stripl can accept _any_ subtype of 
 const(char)[] and return that exact type. Inside the function, however, 
 the type of s is the type declared, thus restricting its use.

 I need to convince myself that function bodies of this type can be 
 reliably typechecked, but first I wanted to run it by everyone to get a 
 feel of it.

 Equivariant functions are not (necessarily) templates and can be used as 
 virtual functions. Only one body is generated for one equivariant 
 function, unless other template mechanisms are in vigor.

 Here are some examples:

 a) Simple equivariance

 typeof(s) stripl(const(char)[] s);

 b) Parameterized equivariance

 typeof(s) stripl(S)(S s) if (isSomeString!S);

 c) Equivariance of field:

 typeof(s.ptr) getpointer(const(char)[] s);

 d) Equivariance inside a class/struct declaration:

 class S
 {
     typeof(this) clone();
     typeof(this.field) getfield();
     int field;
 }

 What do you think? I'm almost afraid to post this.


I'm glad you are looking into this.  This is along the same vein as what I 
called 'scoped const' (see 
http://d.puremagic.com/issues/show_bug.cgi?id=1961), but I only addressed 
const variance.

Just in terms of const, I have a case where your solution doesn't help/work.

Easiest case is min/max:

typeof(v1) min(T)(const(T) v1, const(T) v2) { if(v1 < v2) return v1; return 
v2;}

Now, imagine you call it like this:

char[] best = "bb".dup;
best = min(aa, "aa");

If the function and usage are allowed to compile, then this results in best, 
being a char[], to be pointing to an invariant(char)[].

There are two problems that need to be solved here.  First, you need another 
const type.  One that is treated as const, but is implicitly castable back 
to the argument type, and can't be implicitly casted to.  That type modifier 
needs to be perpetuated throughout the function, because you shouldn't be 
able to return things that didn't originate from the input.  If I create a 
temporary variable, I should have to use this modifier to declare the 
variable (in my proposal, at the suggestion of Janice, I used 'inout', a 
dead keyword).  This guarantees that your output is a subset of the input.

An example of how min looks in my proposal (with the proposed 'inout' 
keyword):

inout(T) min(T)(inout(T) v1, inout(T) v2)

The second problem is, you want the return type to be dependent on both v1 
and v2.  In my proposal, the return type could depend on multiple arguments, 
and if they varied by constancy, the return type was defaulted to const, as 
this is the only possible type that anything can be casted to.

You might be tempted to do something like this:

typeof(v1) min(T)(const(T) v1, typeof(v1) v2)

But then if you pass in the mutable version as the first, the function fails 
to compile in the usage I have above.

In terms of the auto casting to derived types (not just const), I have to 
get my head around it before I can think of possible counter cases, but 
const is definitely broken by your solution (or at least, the solution 
doesn't handle all cases).

-Steve
Oct 13 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Steven Schveighoffer" wrote

 You might be tempted to do something like this:

 typeof(v1) min(T)(const(T) v1, typeof(v1) v2)

 But then if you pass in the mutable version as the first, the function 
 fails to compile in the usage I have above.


d'oh!  A valid solution should fail to compile that usage ;)

I meant this usage (which should compile).

const(char)[] x = "bb";
x = min("aa", x);

-Steve
Oct 13 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote
 I'm glad you are looking into this.  This is along the same vein as what I 
 called 'scoped const' (see 
 http://d.puremagic.com/issues/show_bug.cgi?id=1961), but I only addressed 
 const variance.
 
 Just in terms of const, I have a case where your solution doesn't help/work.
 
 Easiest case is min/max:
 
 typeof(v1) min(T)(const(T) v1, const(T) v2) { if(v1 < v2) return v1; return 
 v2;}
 
 Now, imagine you call it like this:
 
 char[] best = "bb".dup;
 best = min(aa, "aa");
 
 If the function and usage are allowed to compile, then this results in best, 
 being a char[], to be pointing to an invariant(char)[].


The function doesn't compile per the typechecking I discussed in a 
different post.


 There are two problems that need to be solved here.  First, you need another 
 const type.  One that is treated as const, but is implicitly castable back 
 to the argument type, and can't be implicitly casted to.  That type modifier 
 needs to be perpetuated throughout the function, because you shouldn't be 
 able to return things that didn't originate from the input.  If I create a 
 temporary variable, I should have to use this modifier to declare the 
 variable (in my proposal, at the suggestion of Janice, I used 'inout', a 
 dead keyword).  This guarantees that your output is a subset of the input.


I think the typedef-based approach could work (and be that type you 
mention).


 An example of how min looks in my proposal (with the proposed 'inout' 
 keyword):
 
 inout(T) min(T)(inout(T) v1, inout(T) v2)
 
 The second problem is, you want the return type to be dependent on both v1 
 and v2.  In my proposal, the return type could depend on multiple arguments, 
 and if they varied by constancy, the return type was defaulted to const, as 
 this is the only possible type that anything can be casted to.
 
 You might be tempted to do something like this:
 
 typeof(v1) min(T)(const(T) v1, typeof(v1) v2)
 
 But then if you pass in the mutable version as the first, the function fails 
 to compile in the usage I have above.


My solution does theoretically support multiple types by including them 
in the typeof expression. Walter, however, mentioned potential 
difficulties with implementing them.


Andrei
Oct 13 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote
 I'm glad you are looking into this.  This is along the same vein as what 
 I called 'scoped const' (see 
 http://d.puremagic.com/issues/show_bug.cgi?id=1961), but I only addressed 
 const variance.

 Just in terms of const, I have a case where your solution doesn't 
 help/work.

 Easiest case is min/max:

 typeof(v1) min(T)(const(T) v1, const(T) v2) { if(v1 < v2) return v1; 
 return v2;}

 Now, imagine you call it like this:

 char[] best = "bb".dup;
 best = min(aa, "aa");

 If the function and usage are allowed to compile, then this results in 
 best, being a char[], to be pointing to an invariant(char)[].


 The function doesn't compile per the typechecking I discussed in a 
 different post.


I read that, but I didn't understand it, I'll go read it again ;)


 There are two problems that need to be solved here.  First, you need 
 another const type.  One that is treated as const, but is implicitly 
 castable back to the argument type, and can't be implicitly casted to. 
 That type modifier needs to be perpetuated throughout the function, 
 because you shouldn't be able to return things that didn't originate from 
 the input.  If I create a temporary variable, I should have to use this 
 modifier to declare the variable (in my proposal, at the suggestion of 
 Janice, I used 'inout', a dead keyword).  This guarantees that your 
 output is a subset of the input.


 I think the typedef-based approach could work (and be that type you 
 mention).


So in your scheme, the following is true?

void foo2(const(char)[] arg);

typeof(arg) foo3(const(char)[] arg);

typeof(arg1)  foo(const(char)[] arg1)
{
   arg1 = "foo"; // fails
   typeof(arg1) arg1copy = arg1; // ok
   const(char)[] arg2 = arg1; // ok
   foo2(arg1); // ok
   arg1copy = foo3(arg1); // ok
   return arg1copy; // ok
}

If that's the case, then the scheme is similar to what I had in mind.

I don't really like the typeof(arg1) to use as the type name for temporary 
variables inside the function, it seems innocuous.  Perhaps a special type 
name can be implicitly declared inside the function?


 An example of how min looks in my proposal (with the proposed 'inout' 
 keyword):

 inout(T) min(T)(inout(T) v1, inout(T) v2)

 The second problem is, you want the return type to be dependent on both 
 v1 and v2.  In my proposal, the return type could depend on multiple 
 arguments, and if they varied by constancy, the return type was defaulted 
 to const, as this is the only possible type that anything can be casted 
 to.

 You might be tempted to do something like this:

 typeof(v1) min(T)(const(T) v1, typeof(v1) v2)

 But then if you pass in the mutable version as the first, the function 
 fails to compile in the usage I have above.


 My solution does theoretically support multiple types by including them in 
 the typeof expression. Walter, however, mentioned potential difficulties 
 with implementing them.


OK, so how does min look in your scheme?

-Steve
Oct 14 2008
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 What do you think? I'm almost afraid to post this.


It's a lot to swallow all at once, especially if the equivariance 
applies to all type/subtype relationships, and not just the mutability 
of a value. Am I reading that right?

--benji
Oct 13 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu wrote:

 What do you think? I'm almost afraid to post this.


 
 It's a lot to swallow all at once, especially if the equivariance 
 applies to all type/subtype relationships, and not just the mutability 
 of a value. Am I reading that right?



Yes.

Andrei
Oct 13 2008
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu wrote:

 Benji Smith wrote:

 Andrei Alexandrescu wrote:

 What do you think? I'm almost afraid to post this.


 It's a lot to swallow all at once, especially if the equivariance 
 applies to all type/subtype relationships, and not just the mutability 
 of a value. Am I reading that right?


 
 
 Yes.


Are you sure about that? How would this work for interfaces and classes 
that implement them?
Remember: Interface references currently don't point to the object 
vtable at the beginning of an object but to the interface vptr inside 
the object.
Unless that was changed/is going to change? (For example, interface 
references could be implemented as "fat pointers" consisting of { object 
ptr, interface vptr } instead of the current { pointer to interface vptr 
}, which could make this easier to implement)
Oct 15 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 In programming languages growing the vocabulary indiscriminately is 
 worse because it chews into the vocabulary available to user-defined 
 symbols.


What chews now is library's vocabulary:

class Director{...}
class Department
{
  Director Director() //compiler: ^3^ chuuu~
  { return director; }
}
Oct 14 2008
parent KennyTM~ <kennytm gmail.com> writes:
ore-sama wrote:

 Andrei Alexandrescu Wrote:
 

 In programming languages growing the vocabulary indiscriminately is 
 worse because it chews into the vocabulary available to user-defined 
 symbols.


 
 What chews now is library's vocabulary:
 
 class Director{...}
 class Department
 {
   Director Director() //compiler: ^3^ chuuu~
   { return director; }
 }
 



that's why namespaces are introduced.
Oct 14 2008
prev sibling next sibling parent ore-sama <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 I'm glad there's interest in equivariant functions. Let me share below 
 how I think they can be properly typechecked.
 
 The general signature of an equivariant function is:
 
 typeof(expression_involving(pk)) fun(T1 p1, ..., Tk pk, ..., Tn pn);
 
 Let's see this typechecking at work:
 
 1. Accessing a field:
 
 typeof(s.ptr) at(const char[] s, uint i) { return s.ptr + i; }
 
 Typecheck with a typedef for const char[], yielding:
 
 typedef const(char[]) __Surrogate;
 typeof(__Surrogate.init.ptr) at(__Surrogate s, uint i)
 { return s.ptr + i; }
 
 Pass.


How to typecheck it in the case of mutable argument?
typedef surrogate as mutable type?

In all three variants of function only const and/or equivariant methods should
be called on surrogated parameter.
Oct 14 2008
prev sibling next sibling parent ore-sama <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 Even in natural language identical words are reused for various 
 different meanings.
 Also, whenever a feature is to be integrated into the language, it is 
 preferable if possible to integrate it under an existing concept instead 
 of "allocating" a new concept to it.


Another issue with omonymous keywords is simple syntax highlighters can't
distinguish attribute from statement and highlight them in different ways:
scope, invariant, in.
Oct 14 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);


As another point on this, I think someone else mentioned it, but I can't 
find the post.

I don't like the way this looks.  The way it reads is 'stripl returns the 
same type as s', but really, the typeof(s) is actually modifying the type of 
the argument also.  This seems very unintuitive.

I understand the need to not change the language, but I think most would 
prefer a syntax where the type modifier is specified on at least the 
argument.  People are going to be extremely confused when they can't treat 
's' like a normal const(char)[].

If the ultimate result is that no intuitive syntax can be made without 
changing the language, then I think it is more important to have this 
feature than to not change the language.

One other syntax that Janice proposed (and I later put into a bugzilla), is 
to use the dead keyword inout.  Meaning, what you send in is what you get 
out.  ref already completely replaces inout, so there is no need to keep it 
under its current meaning:

inout(char)[] stripl(inout(char)[] s);

I'm not in love with this completely, but it has the benefit of not 
requiring a new keyword.

-Steve
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);


 
 As another point on this, I think someone else mentioned it, but I can't 
 find the post.
 
 I don't like the way this looks.  The way it reads is 'stripl returns the 
 same type as s', but really, the typeof(s) is actually modifying the type of 
 the argument also.  This seems very unintuitive.


I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most would 
 prefer a syntax where the type modifier is specified on at least the 
 argument.  People are going to be extremely confused when they can't treat 
 's' like a normal const(char)[].
 
 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.
 
 One other syntax that Janice proposed (and I later put into a bugzilla), is 
 to use the dead keyword inout.  Meaning, what you send in is what you get 
 out.  ref already completely replaces inout, so there is no need to keep it 
 under its current meaning:
 
 inout(char)[] stripl(inout(char)[] s);
 
 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


Also I guess:

class C
{
     Range!(inout(C)) foo() inout;
}

And also:

class Base {}
class Derived : Base {}
inout foo(inout Base b);

I think this could work and doesn't look half bad. Of course, you'll be 
tasked with addressing protests about yet another D1/D2 incompatibility. :o)


Andrei
Oct 14 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I can't 
 find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns the 
 same type as s', but really, the typeof(s) is actually modifying the type 
 of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most would 
 prefer a syntax where the type modifier is specified on at least the 
 argument.  People are going to be extremely confused when they can't 
 treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a bugzilla), 
 is to use the dead keyword inout.  Meaning, what you send in is what you 
 get out.  ref already completely replaces inout, so there is no need to 
 keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


In this last example, what does the inout mean at the front?


 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 incompatibility. 
 :o)


inout is obsolete in D1 also.  The answer to the protest is 'change inout to 
ref.'  At some point, you can make inout invalid in D1, so it doesn't have a 
double meaning.

Not a big deal IMO ;)

-Steve
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I can't 
 find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns the 
 same type as s', but really, the typeof(s) is actually modifying the type 
 of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most would 
 prefer a syntax where the type modifier is specified on at least the 
 argument.  People are going to be extremely confused when they can't 
 treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a bugzilla), 
 is to use the dead keyword inout.  Meaning, what you send in is what you 
 get out.  ref already completely replaces inout, so there is no need to 
 keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


 
 In this last example, what does the inout mean at the front?


Accept and return any subtype of Base.

Andrei
Oct 14 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the language. 
 Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying 
 the type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at least 
 the argument.  People are going to be extremely confused when they 
 can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla), is to use the dead keyword inout.  Meaning, what you send in 
 is what you get out.  ref already completely replaces inout, so there 
 is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


 In this last example, what does the inout mean at the front?


 Accept and return any subtype of Base.


so in this case, inout is equivalent to inout(Base)?  Definitely a nice 
idea, since it can always be implied.  But this makes it look very weird if 
the function is a member:

class X
{
   inout inout foo();
}

Where the first inout is a modifier on the 'this' argument, and the second 
inout is equivalent to inout(X).

Unless Walter is ok with abolishing the ability to put this modifiers at the 
front of member functions? :D

-Steve
Oct 14 2008
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 14 Oct 2008 18:51:56 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant  
 functions without actually adding an explicit feature to the  
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I  
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns  
 the same type as s', but really, the typeof(s) is actually modifying  
 the type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most  
 would prefer a syntax where the type modifier is specified on at  
 least the argument.  People are going to be extremely confused when  
 they can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made  
 without changing the language, then I think it is more important to  
 have this feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a  
 bugzilla), is to use the dead keyword inout.  Meaning, what you send  
 in is what you get out.  ref already completely replaces inout, so  
 there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not  
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


  In this last example, what does the inout mean at the front?


 Accept and return any subtype of Base.

 Andrei


I was first wondering how this would treat things like

   inout foo(Base b, int n);

But then I noticed it saying "inout Base b", so only the argument(s) marked
inout are considered for the return type? Also, this means a maximum of one
inout argument type per function, right?

As for the keyword, I feel inout is better than typeof, and good enough.  
Not
perfect, but good enough.

-- 
Simen
Oct 14 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 14 Oct 2008 22:38:58 +0400, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:


 On Tue, 14 Oct 2008 18:51:56 +0200, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant  
 functions without actually adding an explicit feature to the  
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I  
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl  
 returns the same type as s', but really, the typeof(s) is actually  
 modifying the type of the argument also.  This seems very  
 unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most  
 would prefer a syntax where the type modifier is specified on at  
 least the argument.  People are going to be extremely confused when  
 they can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made  
 without changing the language, then I think it is more important to  
 have this feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a  
 bugzilla), is to use the dead keyword inout.  Meaning, what you send  
 in is what you get out.  ref already completely replaces inout, so  
 there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not  
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


  In this last example, what does the inout mean at the front?


 Accept and return any subtype of Base.

 Andrei


 I was first wondering how this would treat things like

    inout foo(Base b, int n);

 But then I noticed it saying "inout Base b", so only the argument(s)  
 marked
 inout are considered for the return type?


Yes


 Also, this means a maximum of one
 inout argument type per function, right?


No, there were many example of multiple (and even none) inout function  
arguments.


 As for the keyword, I feel inout is better than typeof, and good enough.  
 Not perfect, but good enough.


My concern is that it than 'inout' doesn't express that all the arguments  
marked as inout as bound to each other and actual type is deduced from  
them all. There is a relationship between their types.

inout(A) min(inout(A1) a1, inout(A2) a2);

A1 a1;
A2 a2;

const(A1) ca1;
const(A2) ca2;

invariant(A1) ia1;
invariant(A1) ia2;

auto a = min(a1, ia2); // typeof(a) == const(A) even though neither a1 nor  
ia2 of that type
auto a = min(a1, a2);  // typeof(a) == A

You see, in the example above the return type is changed because type of  
2nd argument is changed. Not only the return type but types of all the  
arguments, too.

auto a = min(ia1, ia2);  // typeof(a) == invariant(A). Now return type is  
changed per 1st argument type change.
Oct 14 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 14 Oct 2008 20:57:56 +0200, Denis Koroskin <2korden gmail.com>  
wrote:


 On Tue, 14 Oct 2008 22:38:58 +0400, Simen Kjaeraas  
 <simen.kjaras gmail.com> wrote:


 On Tue, 14 Oct 2008 18:51:56 +0200, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant  
 functions without actually adding an explicit feature to the  
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I  
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl  
 returns the same type as s', but really, the typeof(s) is actually  
 modifying the type of the argument also.  This seems very  
 unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most  
 would prefer a syntax where the type modifier is specified on at  
 least the argument.  People are going to be extremely confused when  
 they can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made  
 without changing the language, then I think it is more important to  
 have this feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a  
 bugzilla), is to use the dead keyword inout.  Meaning, what you  
 send in is what you get out.  ref already completely replaces  
 inout, so there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not  
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


  In this last example, what does the inout mean at the front?


 Accept and return any subtype of Base.

 Andrei


 I was first wondering how this would treat things like

    inout foo(Base b, int n);

 But then I noticed it saying "inout Base b", so only the argument(s)  
 marked
 inout are considered for the return type?


 Yes


 Also, this means a maximum of one
 inout argument type per function, right?


 No, there were many example of multiple (and even none) inout function  
 arguments.


I said argument types, as inout(MyClass) in inout foo(inout(MyClass) a,  
inout(MyClass) b).


 As for the keyword, I feel inout is better than typeof, and good  
 enough. Not perfect, but good enough.


 My concern is that it than 'inout' doesn't express that all the  
 arguments marked as inout as bound to each other and actual type is  
 deduced from them all. There is a relationship between their types.

 inout(A) min(inout(A1) a1, inout(A2) a2);

 A1 a1;
 A2 a2;

 const(A1) ca1;
 const(A2) ca2;

 invariant(A1) ia1;
 invariant(A1) ia2;

 auto a = min(a1, ia2); // typeof(a) == const(A) even though neither a1  
 nor ia2 of that type
 auto a = min(a1, a2);  // typeof(a) == A

 You see, in the example above the return type is changed because type of  
 2nd argument is changed. Not only the return type but types of all the  
 arguments, too.

 auto a = min(ia1, ia2);  // typeof(a) == invariant(A). Now return type  
 is changed per 1st argument type change.


I don't really see this as a problem. Returning mutable or invariant would  
be worse. Anyways, if you need the two arguments to be of the same type,  
I'd prefer this syntax:

   inout min(inout(A) a1, typeof(a1) a2){}

-- 
Simen
Oct 14 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 14 Oct 2008 23:12:43 +0400, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:


 On Tue, 14 Oct 2008 20:57:56 +0200, Denis Koroskin <2korden gmail.com>  
 wrote:


 On Tue, 14 Oct 2008 22:38:58 +0400, Simen Kjaeraas  
 <simen.kjaras gmail.com> wrote:


 On Tue, 14 Oct 2008 18:51:56 +0200, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant  
 functions without actually adding an explicit feature to the  
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I  
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl  
 returns the same type as s', but really, the typeof(s) is actually  
 modifying the type of the argument also.  This seems very  
 unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most  
 would prefer a syntax where the type modifier is specified on at  
 least the argument.  People are going to be extremely confused  
 when they can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made  
 without changing the language, then I think it is more important  
 to have this feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a  
 bugzilla), is to use the dead keyword inout.  Meaning, what you  
 send in is what you get out.  ref already completely replaces  
 inout, so there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of  
 not requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


  In this last example, what does the inout mean at the front?


 Accept and return any subtype of Base.

 Andrei


 I was first wondering how this would treat things like

    inout foo(Base b, int n);

 But then I noticed it saying "inout Base b", so only the argument(s)  
 marked
 inout are considered for the return type?


 Yes


 Also, this means a maximum of one
 inout argument type per function, right?


 No, there were many example of multiple (and even none) inout function  
 arguments.


 I said argument types, as inout(MyClass) in inout foo(inout(MyClass) a,  
 inout(MyClass) b).


Isn't the following example good enough?
inout(A) min(inout(A1) a1, inout(A2) a2); // 3 different types

How about another one:

class Foo
{
     inout this(inout(char)[] chars, inout(int)[] ints)
     {
         this.chars = chars;
         this.ints = ints;
     }

     char[] chars;
     int[] ints;
}

inout(Foo) createFoo(inout(char)[] chars, inout(int)[] ints)
{
     return new Foo(chars, ints);
}

auto foo = createFoo("Hello!", [1, 1, 2, 3, 5, 8]); // typeof(foo) ==  
invariant(Foo)

The basic idea is to get some arrays of different types and return some  
other (corresponding) object. Their types may be completely unrelated!

Also this one:

class Foo
{
     inout(Bar) getBar() inout(this) { return bar; } // takes 'this' of  
type inout(Foo) an returns inout(Bar). Types are unrelated.
     private Bar bar;
}


 As for the keyword, I feel inout is better than typeof, and good  
 enough. Not perfect, but good enough.


 My concern is that it than 'inout' doesn't express that all the  
 arguments marked as inout as bound to each other and actual type is  
 deduced from them all. There is a relationship between their types.

 inout(A) min(inout(A1) a1, inout(A2) a2);

 A1 a1;
 A2 a2;

 const(A1) ca1;
 const(A2) ca2;

 invariant(A1) ia1;
 invariant(A1) ia2;

 auto a = min(a1, ia2); // typeof(a) == const(A) even though neither a1  
 nor ia2 of that type
 auto a = min(a1, a2);  // typeof(a) == A

 You see, in the example above the return type is changed because type  
 of 2nd argument is changed. Not only the return type but types of all  
 the arguments, too.

 auto a = min(ia1, ia2);  // typeof(a) == invariant(A). Now return type  
 is changed per 1st argument type change.


 I don't really see this as a problem. Returning mutable or invariant  
 would be worse. Anyways, if you need the two arguments to be of the same  
 type, I'd prefer this syntax:

    inout min(inout(A) a1, typeof(a1) a2){}


Ouch! This one hurts. Yet it is inconsistent with multiple argument types.
Besides, what advantages of it do you see over "inout min(inout(A) a1,  
inout(A) a2);"?
Oct 14 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 14 Oct 2008 21:30:47 +0200, Denis Koroskin <2korden gmail.com>  
wrote:


 On Tue, 14 Oct 2008 23:12:43 +0400, Simen Kjaeraas  
 <simen.kjaras gmail.com> wrote:


 On Tue, 14 Oct 2008 20:57:56 +0200, Denis Koroskin <2korden gmail.com>  
 wrote:


 On Tue, 14 Oct 2008 22:38:58 +0400, Simen Kjaeraas  
 <simen.kjaras gmail.com> wrote:


 Also, this means a maximum of one
 inout argument type per function, right?


 No, there were many example of multiple (and even none) inout function  
 arguments.


 I said argument types, as inout(MyClass) in inout foo(inout(MyClass) a,  
 inout(MyClass) b).


 Isn't the following example good enough?
 inout(A) min(inout(A1) a1, inout(A2) a2); // 3 different types


It is, now that I reread it, and see that it's not all A's. :p



 As for the keyword, I feel inout is better than typeof, and good  
 enough. Not perfect, but good enough.


 My concern is that it than 'inout' doesn't express that all the  
 arguments marked as inout as bound to each other and actual type is  
 deduced from them all. There is a relationship between their types.

 inout(A) min(inout(A1) a1, inout(A2) a2);

 A1 a1;
 A2 a2;

 const(A1) ca1;
 const(A2) ca2;

 invariant(A1) ia1;
 invariant(A1) ia2;

 auto a = min(a1, ia2); // typeof(a) == const(A) even though neither a1  
 nor ia2 of that type
 auto a = min(a1, a2);  // typeof(a) == A

 You see, in the example above the return type is changed because type  
 of 2nd argument is changed. Not only the return type but types of all  
 the arguments, too.

 auto a = min(ia1, ia2);  // typeof(a) == invariant(A). Now return type  
 is changed per 1st argument type change.


 I don't really see this as a problem. Returning mutable or invariant  
 would be worse. Anyways, if you need the two arguments to be of the  
 same type, I'd prefer this syntax:

    inout min(inout(A) a1, typeof(a1) a2){}


 Ouch! This one hurts. Yet it is inconsistent with multiple argument  
 types.


With my newfound knowledge of this working on multiple argument types, I
agree.


 Besides, what advantages of it do you see over "inout min(inout(A) a1,  
 inout(A) a2);"?


Mainly that it says "the type of a2 is the same as the type of a1",
while inout says "the return type is somehow dependant upon the types
of a1 and a2" (probably the lowest common denominator). If I feed mutable
and invariant data into a function, and can receive either of those back,
I expect it to be const. If I want to feed data of the same type/
constancy to a function, and want it to inform me if I'm doing it wrong,
I would state that they should be of the same type/constancy, not that
the return value is dependant upon both of them.

-- 
Simen
Oct 14 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Simen Kjaeraas wrote:

 I don't really see this as a problem. Returning mutable or invariant 
 would be worse. Anyways, if you need the two arguments to be of the same 
 type, I'd prefer this syntax:
 
   inout min(inout(A) a1, typeof(a1) a2){}


IMHO we could simplify by discounting min. The major need is to pass the 
type of one argument only. Min and max are templates anyway, and for 
templates we have other ways to make things work.

Andrei
Oct 14 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 14 Oct 2008 23:45:32 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Simen Kjaeraas wrote:

 I don't really see this as a problem. Returning mutable or invariant  
 would be worse. Anyways, if you need the two arguments to be of the  
 same type, I'd prefer this syntax:
    inout min(inout(A) a1, typeof(a1) a2){}


 IMHO we could simplify by discounting min. The major need is to pass the  
 type of one argument only. Min and max are templates anyway, and for  
 templates we have other ways to make things work.

 Andrei


IMHO, the solution should be consistent and general enough to cover  
templates, too, as well as zero, single and multiple input arguments.  
Templates would benefit from it, too, reducing the generated file size  
(there are many complains about this issue).
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Tue, 14 Oct 2008 23:45:32 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Simen Kjaeraas wrote:

 I don't really see this as a problem. Returning mutable or invariant 
 would be worse. Anyways, if you need the two arguments to be of the 
 same type, I'd prefer this syntax:
    inout min(inout(A) a1, typeof(a1) a2){}


 IMHO we could simplify by discounting min. The major need is to pass 
 the type of one argument only. Min and max are templates anyway, and 
 for templates we have other ways to make things work.

 Andrei


 
 IMHO, the solution should be consistent and general enough to cover 
 templates, too, as well as zero, single and multiple input arguments. 
 Templates would benefit from it, too, reducing the generated file size 
 (there are many complains about this issue).


If you can find a solution that is simple and general enough, my hat is 
off to you.

Andrei
Oct 14 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Oct 2008 05:30:52 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 On Tue, 14 Oct 2008 23:45:32 +0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 Simen Kjaeraas wrote:

 I don't really see this as a problem. Returning mutable or invariant  
 would be worse. Anyways, if you need the two arguments to be of the  
 same type, I'd prefer this syntax:
    inout min(inout(A) a1, typeof(a1) a2){}


 IMHO we could simplify by discounting min. The major need is to pass  
 the type of one argument only. Min and max are templates anyway, and  
 for templates we have other ways to make things work.

 Andrei


  IMHO, the solution should be consistent and general enough to cover  
 templates, too, as well as zero, single and multiple input arguments.  
 Templates would benefit from it, too, reducing the generated file size  
 (there are many complains about this issue).


 If you can find a solution that is simple and general enough, my hat is  
 off to you.

 Andrei


We are here to discuss it. I made many suggestions, but I don't know  
whether they fine, too complex or just lame untill someone comments it  
(interesting enough, some reply without reading). What's wrong with  
typeof(this) (I just generalized your clone() idea combined with implicit  
upcasting suggested by Steven)? The "I don't like it" comment would be  
useful, too.

What's wrong with inout/whatever? So far you brought just one  
'problematic' example:

inout(C) foo(inout(B) function(inout(A)) fn);

I believe this is as meaningless as
inout(A) foo(); // what does it return? A, const(A) or invariant(A)?

and thus should be statically disallowed.

I mean, inout(return) doesn't have any sense unless a function accepts  
some inout(parameter):

inout(B) foo(inout(A) a); // ok

// your example with an added inout(in) parameter. Now it is fine
inout(C) foo(inout(C) c, inout(B) function(inout(A) a) fn);

In the last example, constancy of return value matches constancy of input  
parameter.
Oct 14 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 15, 2008 at 2:31 PM, Denis Koroskin <2korden gmail.com> wrote:

 On Wed, 15 Oct 2008 05:30:52 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 On Tue, 14 Oct 2008 23:45:32 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Simen Kjaeraas wrote:

 I don't really see this as a problem. Returning mutable or invariant
 would be worse. Anyways, if you need the two arguments to be of the same
 type, I'd prefer this syntax:
   inout min(inout(A) a1, typeof(a1) a2){}


 IMHO we could simplify by discounting min. The major need is to pass the
 type of one argument only. Min and max are templates anyway, and for
 templates we have other ways to make things work.

 Andrei


  IMHO, the solution should be consistent and general enough to cover
 templates, too, as well as zero, single and multiple input arguments.
 Templates would benefit from it, too, reducing the generated file size
 (there are many complains about this issue).


 If you can find a solution that is simple and general enough, my hat is
 off to you.

 Andrei


 We are here to discuss it. I made many suggestions, but I don't know whether
 they fine, too complex or just lame untill someone comments it (interesting
 enough, some reply without reading). What's wrong with typeof(this) (I just
 generalized your clone() idea combined with implicit upcasting suggested by
 Steven)? The "I don't like it" comment would be useful, too.

 What's wrong with inout/whatever? So far you brought just one 'problematic'
 example:

 inout(C) foo(inout(B) function(inout(A)) fn);

 I believe this is as meaningless as
 inout(A) foo(); // what does it return? A, const(A) or invariant(A)?

 and thus should be statically disallowed.

 I mean, inout(return) doesn't have any sense unless a function accepts some
 inout(parameter):

 inout(B) foo(inout(A) a); // ok

 // your example with an added inout(in) parameter. Now it is fine
 inout(C) foo(inout(C) c, inout(B) function(inout(A) a) fn);

 In the last example, constancy of return value matches constancy of input
 parameter.


.. and inout(B), inout(A) there have that same constancy?  Or is their
constancy unrelated?

--bb
Oct 14 2008
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Oct 2008 09:51:59 +0400, Bill Baxter <wbaxter gmail.com> wrote:


 inout(C) foo(inout(C) c, inout(B) function(inout(A) a) fn);

 In the last example, constancy of return value matches constancy of  
 input
 parameter.


 .. and inout(B), inout(A) there have that same constancy?  Or is their
 constancy unrelated?

 --bb


To answer this I need to take a use case and look at a concrete function  
implementation:


-------
void testInoutFunction(inout(char[]) function(inout(char)[]) fn)
{
     char[] a1 = "hello".dup;
     a1 = fn(a1);
     writefln(a1);

     const(char)[] a2 = "hello";
     a2 = b(a2);
     writefln(a2);

     invariant(char)[] a3 = "hello";
     a3 = b(a3);
     writefln(a3);
}

inout(char)[] foo(inout(char)[] a);
testInoutFunction(&foo);

I think this is a valid use case. Note that testInoutFunction doesn't take  
any inout() params and the inout() constancy expantion doesn't take place  
at the call-time, i.e.

void testInoutFunction(inout(char[]) function(inout(char)[]) fn)

doesn't transform into one of these:
void testInoutFunction(char[] function(char[]) fn);
void testInoutFunction(const(char[]) function(const(char)[]) fn);
void testInoutFunction(invariant(char[]) function(invariant(char)[]) fn);

Adding an additional parameter doesn't change a bit (function shouldn't  
change its behaviour drastically given additional parameter):

inout(char)[] testInoutFunction(inout(char)[] a, inout(char[])  
function(inout(char)[]) fn)
{
     testInoutFunction(fn); // call zero-arg version
     // do something with a
     return a[1..$];
}

So a rule here is that inout() constancy expansion  doesn't take place for  
delegate and function pointers.


-------

In this case, inout() constancy expantion does take place on delegates and  
function pointers. Let's see if it is useful:

char[] foo1(char[] a);
invariant(char)[] foo2(invariant(char)[] a);

void testInoutFunction(inout(char[]) function(inout(char)[]) fn);

testInoutFunction(&foo1); // assume, we wanna call like this
testInoutFunction(&foo2); // and like this

Given these uses cases, what assumptions can testInoutFunction make and  
actions take?

void testInoutFunction(inout(char[]) function(inout(char)[]) fn)
{
     char[] a = "hello".dup;
     a = fn(a); // invalid, violates foo2 typechecking

     invariant(char)[] b = "hello";
     b = fn(b); // invalid, violates foo1 typechecking

     const(char)[] c = "hello";
     c = fn(c); // ok
}

See, testInoutFunction's actually can't do much. In fact it is no  
different from
void testInoutFunction(const(char)[] function(char(char)[]) fn);

So the second use case is in fact incorrect and should not be allowed.

Back to the original example:

 inout(C) foo(inout(C) c, inout(B) function(inout(A) a) fn);


Type of return value here depends on type of first argument (c), type of  
fn doesn't vary, it is always the same.
Oct 15 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote

 On Wed, Oct 15, 2008 at 2:31 PM, Denis Koroskin <2korden gmail.com> wrote:

 On Wed, 15 Oct 2008 05:30:52 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Denis Koroskin wrote:

 On Tue, 14 Oct 2008 23:45:32 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Simen Kjaeraas wrote:

 I don't really see this as a problem. Returning mutable or invariant
 would be worse. Anyways, if you need the two arguments to be of the 
 same
 type, I'd prefer this syntax:
   inout min(inout(A) a1, typeof(a1) a2){}


 IMHO we could simplify by discounting min. The major need is to pass 
 the
 type of one argument only. Min and max are templates anyway, and for
 templates we have other ways to make things work.

 Andrei


  IMHO, the solution should be consistent and general enough to cover
 templates, too, as well as zero, single and multiple input arguments.
 Templates would benefit from it, too, reducing the generated file size
 (there are many complains about this issue).


 If you can find a solution that is simple and general enough, my hat is
 off to you.

 Andrei


 We are here to discuss it. I made many suggestions, but I don't know 
 whether
 they fine, too complex or just lame untill someone comments it 
 (interesting
 enough, some reply without reading). What's wrong with typeof(this) (I 
 just
 generalized your clone() idea combined with implicit upcasting suggested 
 by
 Steven)? The "I don't like it" comment would be useful, too.

 What's wrong with inout/whatever? So far you brought just one 
 'problematic'
 example:

 inout(C) foo(inout(B) function(inout(A)) fn);

 I believe this is as meaningless as
 inout(A) foo(); // what does it return? A, const(A) or invariant(A)?

 and thus should be statically disallowed.

 I mean, inout(return) doesn't have any sense unless a function accepts 
 some
 inout(parameter):

 inout(B) foo(inout(A) a); // ok

 // your example with an added inout(in) parameter. Now it is fine
 inout(C) foo(inout(C) c, inout(B) function(inout(A) a) fn);

 In the last example, constancy of return value matches constancy of input
 parameter.


 .. and inout(B), inout(A) there have that same constancy?  Or is their
 constancy unrelated?


inout is a type modifier.  At the time you call foo, inout(B) and inout(A) 
are not resolved to anything yet.  But when you call fn, that is when the 
compiler determines what inout should resolve to.  Like any signature, it is 
telling you what the type of the parameters will be during the fn function. 
However, the special inout modifier tells the compiler it is safe to cast 
back to the original parameter constancy (or in the case of mutilple 
parameters, the greatest common constancy).

-Steve
Oct 15 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Denis Koroskin wrote:

 On Tue, 14 Oct 2008 22:38:58 +0400, Simen Kjaeraas 
 <simen.kjaras gmail.com> wrote:
 

 On Tue, 14 Oct 2008 18:51:56 +0200, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the 
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl 
 returns the same type as s', but really, the typeof(s) is actually 
 modifying the type of the argument also.  This seems very 
 unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at 
 least the argument.  People are going to be extremely confused 
 when they can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made 
 without changing the language, then I think it is more important 
 to have this feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla), is to use the dead keyword inout.  Meaning, what you 
 send in is what you get out.  ref already completely replaces 
 inout, so there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of 
 not requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);


  In this last example, what does the inout mean at the front?


 Accept and return any subtype of Base.

 Andrei


 I was first wondering how this would treat things like

    inout foo(Base b, int n);

 But then I noticed it saying "inout Base b", so only the argument(s) 
 marked
 inout are considered for the return type?


 
 Yes
 

 Also, this means a maximum of one
 inout argument type per function, right?


 
 No, there were many example of multiple (and even none) inout function 
 arguments.
 

 As for the keyword, I feel inout is better than typeof, and good 
 enough. Not perfect, but good enough.


 
 My concern is that it than 'inout' doesn't express that all the 
 arguments marked as inout as bound to each other and actual type is 
 deduced from them all. There is a relationship between their types.
 
 inout(A) min(inout(A1) a1, inout(A2) a2);
 
 A1 a1;
 A2 a2;
 
 const(A1) ca1;
 const(A2) ca2;
 
 invariant(A1) ia1;
 invariant(A1) ia2;
 
 auto a = min(a1, ia2); // typeof(a) == const(A) even though neither a1 
 nor ia2 of that type
 auto a = min(a1, a2);  // typeof(a) == A
 
 You see, in the example above the return type is changed because type of 
 2nd argument is changed. Not only the return type but types of all the 
 arguments, too.
 
 auto a = min(ia1, ia2);  // typeof(a) == invariant(A). Now return type 
 is changed per 1st argument type change.


Er.... isn't that the point. If I pass two mutable arguments to min(), I 
want a mutable back. If I pass two invariant (immutable, hopefully!) 
arguments to min() I want an invariant back. Otherwise, I want a const 
back. That's why this syntax is needed at all.
Oct 14 2008
parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Oct 2008 00:59:44 +0400, Robert Fraser  
<fraserofthenight gmail.com> wrote:


 Denis Koroskin wrote:

 [snip]
  My concern is that it than 'inout' doesn't express that all the  
 arguments marked as inout as bound to each other and actual type is  
 deduced from them all. There is a relationship between their types.
  inout(A) min(inout(A1) a1, inout(A2) a2);
  A1 a1;
 A2 a2;
  const(A1) ca1;
 const(A2) ca2;
  invariant(A1) ia1;
 invariant(A1) ia2;
  auto a = min(a1, ia2); // typeof(a) == const(A) even though neither a1  
 nor ia2 of that type
 auto a = min(a1, a2);  // typeof(a) == A
  You see, in the example above the return type is changed because type  
 of 2nd argument is changed. Not only the return type but types of all  
 the arguments, too.
  auto a = min(ia1, ia2);  // typeof(a) == invariant(A). Now return type  
 is changed per 1st argument type change.


 Er.... isn't that the point. If I pass two mutable arguments to min(), I  
 want a mutable back. If I pass two invariant (immutable, hopefully!)  
 arguments to min() I want an invariant back. Otherwise, I want a const  
 back. That's why this syntax is needed at all.


Yes, it's all about this. My point is that 'inout' keyword is not very  
descriptive in this situation. The behaviour, however, is fine.
Oct 14 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the 
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying 
 the type of the argument also.  This seems very unintuitive.


 
 I agree. We need to look for a better notation.
 

 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at least 
 the argument.  People are going to be extremely confused when they 
 can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla), is to use the dead keyword inout.  Meaning, what you send 
 in is what you get out.  ref already completely replaces inout, so 
 there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 
 Also I guess:
 
 class C
 {
     Range!(inout(C)) foo() inout;
 }
 
 And also:
 
 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);
 
 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 incompatibility. 
 :o)
 
 
 Andrei


I'm afraid the meaning of inout here is very unclear without explanation.
Oct 14 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"KennyTM~" wrote

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I can't 
 find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying the 
 type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most would 
 prefer a syntax where the type modifier is specified on at least the 
 argument.  People are going to be extremely confused when they can't 
 treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a bugzilla), 
 is to use the dead keyword inout.  Meaning, what you send in is what you 
 get out.  ref already completely replaces inout, so there is no need to 
 keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 incompatibility. 
 :o)


 Andrei


 I'm afraid the meaning of inout here is very unclear without explanation.


You are correct.  It means 'what you send in as input gets returned as 
output.'

In reality, it's not the best name for this type of thing, but it has the 
benefit of using a defunct keyword -- no new keywords necessary.

I can't think of a really good keyword that is short and would not require 
explanation.  Perhaps you can?  Then we have to weigh the benefits of having 
a new keyword vs. having to post an explanation as to what it means.  My 
guess is we'll have to post an explanation no matter what.

-Steve
Oct 14 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 14 Oct 2008 21:04:01 +0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 "KennyTM~" wrote

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant  
 functions
 without actually adding an explicit feature to the language.  
 Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I  
 can't
 find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns
 the same type as s', but really, the typeof(s) is actually modifying  
 the
 type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most  
 would
 prefer a syntax where the type modifier is specified on at least the
 argument.  People are going to be extremely confused when they can't
 treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without
 changing the language, then I think it is more important to have this
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a  
 bugzilla),
 is to use the dead keyword inout.  Meaning, what you send in is what  
 you
 get out.  ref already completely replaces inout, so there is no need  
 to
 keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be
 tasked with addressing protests about yet another D1/D2  
 incompatibility.
 :o)


 Andrei






I think that basic idea is very good! (for some reason I was bound to  
constness issue and didn't think about the latter example).


 I'm afraid the meaning of inout here is very unclear without  
 explanation.


 You are correct.  It means 'what you send in as input gets returned as
 output.'

 In reality, it's not the best name for this type of thing, but it has the
 benefit of using a defunct keyword -- no new keywords necessary.

 I can't think of a really good keyword that is short and would not  
 require
 explanation.  Perhaps you can?  Then we have to weigh the benefits of  
 having
 a new keyword vs. having to post an explanation as to what it means.  My
 guess is we'll have to post an explanation no matter what.

 -Steve


I have previously proposed the 'same' keyword:

same(Base) foo(same(Base) bar)
{
    bar.callSomeBaseMethod();
    return bar;
}

foo(new Derived());

interface IClonable {
     same(this) clone();
}

It is short and very descriptive.

Frankly speaking, I don't see the difference between inout or some other  
keyword. You either ditch inout and introduce FOO or obsolete inout and  
reuse it. Both have similar effect: some code is broken and needs fixing  
(because inout doesn't work anymore), a new keyword is introduced to  
denote the feature. The only difference is a possible name collision that  
any new keyword might introduce. But it is nothing to worry about, because  
short and meaningful keywords are more important than some potentially  
broken (and easily fixable) code for the language in a long run.
Oct 14 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Denis Koroskin wrote:

 On Tue, 14 Oct 2008 21:04:01 +0400, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:
 

 "KennyTM~" wrote

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions
 without actually adding an explicit feature to the language. 
 Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't
 find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns
 the same type as s', but really, the typeof(s) is actually 
 modifying the
 type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most 
 would
 prefer a syntax where the type modifier is specified on at least the
 argument.  People are going to be extremely confused when they can't
 treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without
 changing the language, then I think it is more important to have this
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla),
 is to use the dead keyword inout.  Meaning, what you send in is 
 what you
 get out.  ref already completely replaces inout, so there is no 
 need to
 keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be
 tasked with addressing protests about yet another D1/D2 
 incompatibility.
 :o)


 Andrei






 
 I think that basic idea is very good! (for some reason I was bound to 
 constness issue and didn't think about the latter example).
 

 I'm afraid the meaning of inout here is very unclear without 
 explanation.


 You are correct.  It means 'what you send in as input gets returned as
 output.'

 In reality, it's not the best name for this type of thing, but it has the
 benefit of using a defunct keyword -- no new keywords necessary.

 I can't think of a really good keyword that is short and would not 
 require
 explanation.  Perhaps you can?  Then we have to weigh the benefits of 
 having
 a new keyword vs. having to post an explanation as to what it means.  My
 guess is we'll have to post an explanation no matter what.

 -Steve


 
 I have previously proposed the 'same' keyword:
 
 same(Base) foo(same(Base) bar)
 {
    bar.callSomeBaseMethod();
    return bar;
 }
 
 foo(new Derived());
 
 interface IClonable {
     same(this) clone();
 }
 
 It is short and very descriptive.
 
 Frankly speaking, I don't see the difference between inout or some other 
 keyword. You either ditch inout and introduce FOO or obsolete inout and 
 reuse it. Both have similar effect: some code is broken and needs fixing 
 (because inout doesn't work anymore), a new keyword is introduced to 
 denote the feature. The only difference is a possible name collision 
 that any new keyword might introduce. But it is nothing to worry about, 
 because short and meaningful keywords are more important than some 
 potentially broken (and easily fixable) code for the language in a long 
 run.


“same” seems to be a common identifier though...

“inout” already has an equivalent keyword. It is called “ref”.
Oct 14 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 14 Oct 2008 22:16:33 +0400, KennyTM~ <kennytm gmail.com> wrote:


 “same” seems to be a common identifier though..

 “inout” already has an equivalent keyword. It is called “ref”.


Yeah, I know :)
Thanks anyway.

But is there any reason to worry about name collision? I just grep'd about  
20Mb of C++ source code and didn't find *a single* usage of `same' outside  
of the comments.
Oct 14 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Denis Koroskin" wrote

 On Tue, 14 Oct 2008 22:16:33 +0400, KennyTM~ <kennytm gmail.com> wrote:


 "same" seems to be a common identifier though..

 "inout" already has an equivalent keyword. It is called "ref".


 Yeah, I know :)
 Thanks anyway.

 But is there any reason to worry about name collision? I just grep'd about 
 20Mb of C++ source code and didn't find *a single* usage of `same' outside 
 of the comments.


I'd say if we were to add a keyword, same would be on the list of choices, I 
can't think of a common usage for it.

But you can't deny that in general using a commonly used symbol as a keyword 
might be a bad idea.

For example 'get' or 'next'.

So yes, when adding a keyword, one should be wary of how it affects commonly 
used keywords, and yes, 'same' is a good choice in that regard ;)

For example, when porting Tango to D2, I had to change about 5 or so 
singleton members (and their uses) named 'shared' since it is now a keyword.

-Steve
Oct 14 2008
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
Denis Koroskin wrote:

 On Tue, 14 Oct 2008 22:16:33 +0400, KennyTM~ <kennytm gmail.com> wrote:
 

 “same” seems to be a common identifier though..

 “inout” already has an equivalent keyword. It is called “ref”.


 
 Yeah, I know :)
 Thanks anyway.
 
 But is there any reason to worry about name collision? I just grep'd 
 about 20Mb of C++ source code and didn't find *a single* usage of `same' 
 outside of the comments.


Googled "filetype:cpp same" and got ≥1 obscure results:

void series::init()
{
   hide = false;
   fl_sr2 = same;
   fl_ga = same;
   fl_gb = same;
   // -snip-
}

(http://evgenii.rudnyi.ru/soft/varcomp/varcomp/sumsqrut.cpp)

But no result so far in D. Probably a safe choice after all, but to me 
too un-keyword-like :p.
Oct 14 2008
prev sibling parent ore-sama <spam here.lot> writes:
Denis Koroskin Wrote:


 But is there any reason to worry about name collision? I just grep'd about  
 20Mb of C++ source code and didn't find *a single* usage of `same' outside  
 of the comments.


google codesearch says that "same" is used in mozilla code and "inout" - in
audacity code.
Oct 15 2008
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Steven Schveighoffer wrote:

 "KennyTM~" wrote

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant functions 
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I can't 
 find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying the 
 type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most would 
 prefer a syntax where the type modifier is specified on at least the 
 argument.  People are going to be extremely confused when they can't 
 treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a bugzilla), 
 is to use the dead keyword inout.  Meaning, what you send in is what you 
 get out.  ref already completely replaces inout, so there is no need to 
 keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 incompatibility. 
 :o)


 Andrei


 I'm afraid the meaning of inout here is very unclear without explanation.


 
 You are correct.  It means 'what you send in as input gets returned as 
 output.'
 
 In reality, it's not the best name for this type of thing, but it has the 
 benefit of using a defunct keyword -- no new keywords necessary.
 
 I can't think of a really good keyword that is short and would not require 
 explanation.  Perhaps you can?  Then we have to weigh the benefits of having 
 a new keyword vs. having to post an explanation as to what it means.  My 
 guess is we'll have to post an explanation no matter what.
 
 -Steve 
 
 


Sorry, I can't think of an existing keyword that can clearly qualify the 
purpose in this syntax (“stuff(Type) f(stuff(Type) s)”) either.

By the explanation argument, I actually mean what a programmer first 
sees this feature think of. Presented with Andrei's “typeof” syntax, I 
can at least guess what the function looks like (it returns the same 
type as “s”, OK); but with “inout” I just stopped with "What the heck
is 
going on?!".
Oct 14 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"KennyTM~" wrote

 Steven Schveighoffer wrote:

 "KennyTM~" wrote

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the 
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying 
 the type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at least 
 the argument.  People are going to be extremely confused when they 
 can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla), is to use the dead keyword inout.  Meaning, what you send 
 in is what you get out.  ref already completely replaces inout, so 
 there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 
 incompatibility. :o)


 Andrei


 I'm afraid the meaning of inout here is very unclear without 
 explanation.


 You are correct.  It means 'what you send in as input gets returned as 
 output.'

 In reality, it's not the best name for this type of thing, but it has the 
 benefit of using a defunct keyword -- no new keywords necessary.

 I can't think of a really good keyword that is short and would not 
 require explanation.  Perhaps you can?  Then we have to weigh the 
 benefits of having a new keyword vs. having to post an explanation as to 
 what it means.  My guess is we'll have to post an explanation no matter 
 what.

 -Steve


 Sorry, I can't think of an existing keyword that can clearly qualify the 
 purpose in this syntax ("stuff(Type) f(stuff(Type) s)") either.


I meant a new keyword.  There aren't many existing keywords that I'd want to 
double the meaning of for this (including typeof).  inout is advantageous 
because its current meaning is exactly covered by another keyword.


 By the explanation argument, I actually mean what a programmer first sees 
 this feature think of. Presented with Andrei's "typeof" syntax, I can at 
 least guess what the function looks like (it returns the same type as "s", 
 OK)


Then you failed to see the true meaning of Andrei's syntax ;)  It means that 
the return value is the same as what you used as s to call the function, not 
the type of s (which is whatever the function declares s as).  The return 
type changes depending on what you call it with.

e.g.:

typeof(s) foo(const(char)[] s);

...

char[] x = "hello".dup;

auto x2 = foo(x); // x2 is typed as char[], even though s is declared as 
const(char)[]


 ; but with "inout" I just stopped with "What the heck is going on?!".


At least you are not guessing the wrong thing.  This would probably prompt 
you to look up how inout works in the docs.

I'm not saying that inout is the ideal keyword.  I'm saying that this is a 
novel enough concept that probably people are not going to intuitively see 
what is going on no matter what keyword is used.  They have to learn what 
it's doing by reading docs.  Using typeof as Andrei defined seems 
intuitively to mean something entirely different, and most likely will not 
prompt a lookup of the docs (until it doesn't behave as expected).  Plus it 
doubles the meaning of yet another keyword, which I hate...

e.g. what did you think was happening when you first saw 'mixin'?  Did you 
intuitively think 'oh, this must take what I give it as a compile-time 
generated string and compile it into actual code'.  Probably not, so is 
mixin a bad keyword choice for that feature because you didn't intuitively 
think of it?

-Steve
Oct 14 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Steven Schveighoffer wrote:

 "KennyTM~" wrote

 Steven Schveighoffer wrote:

 "KennyTM~" wrote

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the 
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying 
 the type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at least 
 the argument.  People are going to be extremely confused when they 
 can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla), is to use the dead keyword inout.  Meaning, what you send 
 in is what you get out.  ref already completely replaces inout, so 
 there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 
 incompatibility. :o)


 Andrei


 I'm afraid the meaning of inout here is very unclear without 
 explanation.


 You are correct.  It means 'what you send in as input gets returned as 
 output.'

 In reality, it's not the best name for this type of thing, but it has the 
 benefit of using a defunct keyword -- no new keywords necessary.

 I can't think of a really good keyword that is short and would not 
 require explanation.  Perhaps you can?  Then we have to weigh the 
 benefits of having a new keyword vs. having to post an explanation as to 
 what it means.  My guess is we'll have to post an explanation no matter 
 what.

 -Steve


 Sorry, I can't think of an existing keyword that can clearly qualify the 
 purpose in this syntax ("stuff(Type) f(stuff(Type) s)") either.


 
 I meant a new keyword.  There aren't many existing keywords that I'd want to 
 double the meaning of for this (including typeof).  inout is advantageous 
 because its current meaning is exactly covered by another keyword.
 

 By the explanation argument, I actually mean what a programmer first sees 
 this feature think of. Presented with Andrei's "typeof" syntax, I can at 
 least guess what the function looks like (it returns the same type as "s", 
 OK)


 
 Then you failed to see the true meaning of Andrei's syntax ;)  It means that 
 the return value is the same as what you used as s to call the function, not 
 the type of s (which is whatever the function declares s as).  The return 
 type changes depending on what you call it with.
 
 e.g.:
 
 typeof(s) foo(const(char)[] s);
 
 ...
 
 char[] x = "hello".dup;
 
 auto x2 = foo(x); // x2 is typed as char[], even though s is declared as 
 const(char)[]
 


Yeah I know. It may better be called sth like typeof callsite(s) :)


 ; but with "inout" I just stopped with "What the heck is going on?!".


 
 At least you are not guessing the wrong thing.  This would probably prompt 
 you to look up how inout works in the docs.
 


That could be an advantage. We've different viewpoints :)


 I'm not saying that inout is the ideal keyword.  I'm saying that this is a 
 novel enough concept that probably people are not going to intuitively see 
 what is going on no matter what keyword is used.  They have to learn what 
 it's doing by reading docs.  Using typeof as Andrei defined seems 
 intuitively to mean something entirely different, and most likely will not 
 prompt a lookup of the docs (until it doesn't behave as expected).  Plus it 
 doubles the meaning of yet another keyword, which I hate...
 
 e.g. what did you think was happening when you first saw 'mixin'?  Did you 
 intuitively think 'oh, this must take what I give it as a compile-time 
 generated string and compile it into actual code'.  Probably not, so is 
 mixin a bad keyword choice for that feature because you didn't intuitively 
 think of it?
 


I'd use eval() if I designed the language :p

(Though this also confuses user as eval() is more used in runtime code 
evaluation)


 -Steve
Oct 14 2008
prev sibling parent reply David Gileadi <foo bar.com> writes:
Steven Schveighoffer wrote:

 "KennyTM~" wrote


[snip]

 By the explanation argument, I actually mean what a programmer first sees 
 this feature think of. Presented with Andrei's "typeof" syntax, I can at 
 least guess what the function looks like (it returns the same type as "s", 
 OK)


 
 Then you failed to see the true meaning of Andrei's syntax ;)  It means that 
 the return value is the same as what you used as s to call the function, not 
 the type of s (which is whatever the function declares s as).  The return 
 type changes depending on what you call it with.
 
 e.g.:
 
 typeof(s) foo(const(char)[] s);
 
 ....
 
 char[] x = "hello".dup;
 
 auto x2 = foo(x); // x2 is typed as char[], even though s is declared as 
 const(char)[]
 

 ; but with "inout" I just stopped with "What the heck is going on?!".


 
 At least you are not guessing the wrong thing.  This would probably prompt 
 you to look up how inout works in the docs.
 
 I'm not saying that inout is the ideal keyword.  I'm saying that this is a 
 novel enough concept that probably people are not going to intuitively see 
 what is going on no matter what keyword is used.  They have to learn what 
 it's doing by reading docs.  Using typeof as Andrei defined seems 
 intuitively to mean something entirely different, and most likely will not 
 prompt a lookup of the docs (until it doesn't behave as expected).  Plus it 
 doubles the meaning of yet another keyword, which I hate...
 
 e.g. what did you think was happening when you first saw 'mixin'?  Did you 
 intuitively think 'oh, this must take what I give it as a compile-time 
 generated string and compile it into actual code'.  Probably not, so is 
 mixin a bad keyword choice for that feature because you didn't intuitively 
 think of it?
 
 -Steve 


FWIW I agree with KennyTM~ here--typeof(s) made sense to me, including 
its meaning that you describe above.  This, even though it conflicts 
with the keyword's current meaning.  I suppose it's because "typeof(s)" 
could stand for "some type of s", i.e. some child type of s.

The thing that concerns me about using typeof(s) is your earlier comment:


 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at least 
 the argument.  People are going to be extremely confused when they 
 can't treat 's' like a normal const(char)[].


-Dave
Oct 14 2008
parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 14 Oct 2008 23:17:18 +0400, David Gileadi <foo bar.com> wrote:


 Steven Schveighoffer wrote:

 "KennyTM~" wrote


 [snip]

 By the explanation argument, I actually mean what a programmer first  
 sees this feature think of. Presented with Andrei's "typeof" syntax, I  
 can at least guess what the function looks like (it returns the same  
 type as "s", OK)


  Then you failed to see the true meaning of Andrei's syntax ;)  It  
 means that the return value is the same as what you used as s to call  
 the function, not the type of s (which is whatever the function  
 declares s as).  The return type changes depending on what you call it  
 with.
  e.g.:
  typeof(s) foo(const(char)[] s);
  ....
  char[] x = "hello".dup;
  auto x2 = foo(x); // x2 is typed as char[], even though s is declared  
 as const(char)[]


 ; but with "inout" I just stopped with "What the heck is going on?!".


  At least you are not guessing the wrong thing.  This would probably  
 prompt you to look up how inout works in the docs.
  I'm not saying that inout is the ideal keyword.  I'm saying that this  
 is a novel enough concept that probably people are not going to  
 intuitively see what is going on no matter what keyword is used.  They  
 have to learn what it's doing by reading docs.  Using typeof as Andrei  
 defined seems intuitively to mean something entirely different, and  
 most likely will not prompt a lookup of the docs (until it doesn't  
 behave as expected).  Plus it doubles the meaning of yet another  
 keyword, which I hate...
  e.g. what did you think was happening when you first saw 'mixin'?  Did  
 you intuitively think 'oh, this must take what I give it as a  
 compile-time generated string and compile it into actual code'.   
 Probably not, so is mixin a bad keyword choice for that feature because  
 you didn't intuitively think of it?
  -Steve


 FWIW I agree with KennyTM~ here--typeof(s) made sense to me, including  
 its meaning that you describe above.  This, even though it conflicts  
 with the keyword's current meaning.  I suppose it's because "typeof(s)"  
 could stand for "some type of s", i.e. some child type of s.

 The thing that concerns me about using typeof(s) is your earlier comment:


 I understand the need to not change the language, but I think most  
 would prefer a syntax where the type modifier is specified on at least  
 the argument.  People are going to be extremely confused when they  
 can't treat 's' like a normal const(char)[].


 -Dave


Using typeof, expression would get way too complex and involve some magic  
template trickery like PassQual!() to pass constancy qualifiers from one  
variables to another.
Besides, typeof proved to be insufficient to solve the problem:

typeof(t1) min(T)(T t1, typeof(t1) t2);

T t1 = ...;
auto t2 = ...;

auto t3 = min(t1, t2); // what is the type of t3? Is it T per typeof(t1)?
// Answer is - it depends.. on t2:

T t1 = ...;
const(T) t2 = ...;

auto t3 = min(t1, t2); // typeof(t3) == const(T)
Oct 14 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
KennyTM~ wrote:

 Sorry, I can't think of an existing keyword that can clearly qualify the 
 purpose in this syntax (“stuff(Type) f(stuff(Type) s)”) either.
 
 By the explanation argument, I actually mean what a programmer first 
 sees this feature think of. Presented with Andrei's “typeof” syntax, I 
 can at least guess what the function looks like (it returns the same 
 type as “s”, OK); but with “inout” I just stopped with "What the heck
is 
 going on?!".


I can't:

typeof(s) foo(const(char)[] s)

This looks like it's shorthand for:
const(char)[] foo(const(char)[] s)

And the examples with typeof(A), where A is a type, just didn't make any 
sense.
Oct 14 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the 
 language. Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying 
 the type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at 
 least the argument.  People are going to be extremely confused when 
 they can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made 
 without changing the language, then I think it is more important to 
 have this feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla), is to use the dead keyword inout.  Meaning, what you send 
 in is what you get out.  ref already completely replaces inout, so 
 there is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll 
 be tasked with addressing protests about yet another D1/D2 
 incompatibility. :o)


 Andrei


 
 I'm afraid the meaning of inout here is very unclear without explanation.


I think more explanation is needed for the other case:

inout(char)[] stripl(inout(char)[] s);

What if I pass a const char[]? Is that going to work? In contrast, this 
is simple:

inout stripl(inout const(char)[] s);

Accept and return any subtype of const(char)[].


Andrei
Oct 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 I discussed with Walter a variant that implements equivariant 
 functions without actually adding an explicit feature to the language. 
 Consider:

 typeof(s) stripl(const(char)[] s);


 As another point on this, I think someone else mentioned it, but I 
 can't find the post.

 I don't like the way this looks.  The way it reads is 'stripl returns 
 the same type as s', but really, the typeof(s) is actually modifying 
 the type of the argument also.  This seems very unintuitive.


 I agree. We need to look for a better notation.


 I understand the need to not change the language, but I think most 
 would prefer a syntax where the type modifier is specified on at least 
 the argument.  People are going to be extremely confused when they 
 can't treat 's' like a normal const(char)[].

 If the ultimate result is that no intuitive syntax can be made without 
 changing the language, then I think it is more important to have this 
 feature than to not change the language.

 One other syntax that Janice proposed (and I later put into a 
 bugzilla), is to use the dead keyword inout.  Meaning, what you send in 
 is what you get out.  ref already completely replaces inout, so there 
 is no need to keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 incompatibility. 
 :o)


 Andrei


 I'm afraid the meaning of inout here is very unclear without explanation.


 I think more explanation is needed for the other case:

 inout(char)[] stripl(inout(char)[] s);

 What if I pass a const char[]? Is that going to work? In contrast, this is 
 simple:

 inout stripl(inout const(char)[] s);

 Accept and return any subtype of const(char)[].


I like this a lot better.

What about returning a member?  i.e.:

inout(typeof(s.ptr)) getptr(inout const(char)[] s) { return s.ptr;}

is that what you had in mind?

this syntax is going to be used often, since it's what you would use for an 
accessor.  So it should be simple to understand if possible.

-Steve
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 What about returning a member?  i.e.:
 
 inout(typeof(s.ptr)) getptr(inout const(char)[] s) { return s.ptr;}


Yah there is a recurring problem - we need to find a notation that works 
nicely and expressively for member functions as well as free functions.

For free functions an easy-to-explain-and-understand way is to have 
"inout" mark the incoming / outgoing TYPE entirely, not only its 
qualifier. Then:

inout stripl(inout const(char)[] s);

means: accept any subtype of const(char)[] and call that type "inout" in 
the return type. Then it's easy to access dependent stuff:

typeof(inout.ptr) at(inout const(char)[] s);

Notice that for one-parameter functions there's not even a need to 
specify the inout in the argument list because it's unambiguous:

inout stripl(const(char)[] s);
typeof(inout.ptr) at(const(char)[] s);

When you get into member functions things aren't quite nice:

class A
{
     private int a;
     inout clone() inout; // ehm
     typeof(&inout.a) getPtrToA() inout; // ehm
}


 is that what you had in mind?
 
 this syntax is going to be used often, since it's what you would use for an 
 accessor.  So it should be simple to understand if possible.


Yah I agree. At this point I don't have any solid solution for 
notation... please continue rolling out ideas.


Andrei
Oct 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 What about returning a member?  i.e.:

 inout(typeof(s.ptr)) getptr(inout const(char)[] s) { return s.ptr;}


 Yah there is a recurring problem - we need to find a notation that works 
 nicely and expressively for member functions as well as free functions.

 For free functions an easy-to-explain-and-understand way is to have 
 "inout" mark the incoming / outgoing TYPE entirely, not only its 
 qualifier. Then:

 inout stripl(inout const(char)[] s);

 means: accept any subtype of const(char)[] and call that type "inout" in 
 the return type. Then it's easy to access dependent stuff:

 typeof(inout.ptr) at(inout const(char)[] s);

 Notice that for one-parameter functions there's not even a need to specify 
 the inout in the argument list because it's unambiguous:

 inout stripl(const(char)[] s);
 typeof(inout.ptr) at(const(char)[] s);

 When you get into member functions things aren't quite nice:

 class A
 {
     private int a;
     inout clone() inout; // ehm
     typeof(&inout.a) getPtrToA() inout; // ehm
 }


 is that what you had in mind?

 this syntax is going to be used often, since it's what you would use for 
 an accessor.  So it should be simple to understand if possible.


 Yah I agree. At this point I don't have any solid solution for notation... 
 please continue rolling out ideas.


Damn, I think there is some confusion here, because we are trying to solve 
two related, but unequal problems.

First is const equivariance (is that the right term?).  I want to specify a 
function that treats an argument as const, but does not affect the const 
contract that the caller has with that argument (i.e. my original scoped 
const proposal).

The second is type equivariance.  I want to specify that I will treat an 
argument as a base type, but I will not change the derived type that the 
caller is using.

These are similar, if you consider that const is a 'base type' of its 
mutable or invariant version.  But there is one caveat that is hard to 
explain using this terminology.  const is a type modifier, not a type.  So 
it's not really a base type of a type, and it can be applied to any type in 
existance.  Not the same as specifying a base type.

So the first requirement (const equivariance) does not require that I return 
a derivative of the argument, it requires that I return an argument that is 
part of the input, but contains the same const contract as the passed in 
variable at the *call site*.  It does not require that the return type is 
derived from the input.

It is this first requirement that is the only requirement necessary for 
functions which return unrelated types from their arguments.  i.e., for an 
accessor, which is not returning something of the same type as its argument, 
the only thing that is important to keep the same at the call site is the 
const modifiers.  For example, you can return a base type that is 
automatically converted to a derived type, but that must be accomplished 
with an overridden function.  That is already handled using covariance, and 
I really don't think there is a way to enforce this in the compiler.

An example, a linked list.

class Link
{
   private Link next;
   Link getNext() { return next;}
}

class DerivedLink : Link
{
   int someExtraData;
}

We currently solve this by adding a covariant getNext() to DerivedLink.

But would it be enough to just change the getNext function in the base type 
to:

inout getNext() { return next; } inout;

I don't think it can be enforced.  Because some other Link function can set 
next to another type of Link (possibly a base Link).  It is up to the 
designer of DerivedLink to ensure that next always points to a descendent of 
DerivedLink.  In this case, I think it's a requirement to use covariant 
functions.

However, it *would* be advantageous to declare getNext as not altering the 
const contract of the caller.  That is, it returns the same constancy that 
it is called with (in this example, inout implies const):

inout(Link) getNext() { return next; } inout;

For the second requirement, I can see value in things like call-chaining:

class C
{
  inout doSomething() inout { return this;}
}

class D : C
{
   inout doSomethingElse() inout { return this;}
}

auto d = new D;
d.doSomething().doSomethingElse();

However, the return value MUST be exactly the same value as the input.  If 
it's only the same type, we lose all compiler enforcibility.

So does it make sense to split these two requirements?

I propose to use inout only to deal with const contracts, and use another 
syntax to signify which parameter will be returned:

inout(X) foo(inout(Y) y); // X and Y are unrelated types

a stab at 'returning this exact parameter'
X foo(return X x); // The return value from foo will be x, so the compiler 
is free to upcast automatically.

inout(X) foo(return inout(X) x); // combination, signifies that I will 
return x, and I promise not to modify it in the function.

With this scheme, I think possibly inout might not be as clear...

-Steve
Oct 14 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 These are similar, if you consider that const is a 'base type' of its 
 mutable or invariant version.  But there is one caveat that is hard to 
 explain using this terminology.  const is a type modifier, not a type.  So 
 it's not really a base type of a type, and it can be applied to any type in 
 existance.  Not the same as specifying a base type.


Base type and supertype are not to be confused. By base type I 
understand you mean you actually type class Super{} and class 
Sub:Super{}. The subtyping relation is more general and applies to any 
two types Super and Sub that satisfy a number of constraints.

That const(T) is a supertype of both T and invariant(T) is essential and 
not happenstance. It enshrines the fact that you can always pass a T or 
an invariant(T) into a function. The fact that there is no difference in 
layout and that const is not assignable also means that arrays of 
const(T) are supertypes of both arrays of T and invariant(T), with 
important consequences.



Andrei
Oct 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 These are similar, if you consider that const is a 'base type' of its 
 mutable or invariant version.  But there is one caveat that is hard to 
 explain using this terminology.  const is a type modifier, not a type. 
 So it's not really a base type of a type, and it can be applied to any 
 type in existance.  Not the same as specifying a base type.


 Base type and supertype are not to be confused. By base type I understand 
 you mean you actually type class Super{} and class Sub:Super{}. The 
 subtyping relation is more general and applies to any two types Super and 
 Sub that satisfy a number of constraints.

 That const(T) is a supertype of both T and invariant(T) is essential and 
 not happenstance. It enshrines the fact that you can always pass a T or an 
 invariant(T) into a function. The fact that there is no difference in 
 layout and that const is not assignable also means that arrays of const(T) 
 are supertypes of both arrays of T and invariant(T), with important 
 consequences.


But a type invariant(T) is not a subtype of const(U).  How do you solve this 
problem:

class U
{
   private T field
   public T property() { return field;}
   public invariant(T) property() { return field; } invariant;
   public const(T) property() {return field; } const;
}

Because T is completely unrelated to U, so the inout contract only has to do 
with constancy, not the types.

-Steve
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 These are similar, if you consider that const is a 'base type' of its 
 mutable or invariant version.  But there is one caveat that is hard to 
 explain using this terminology.  const is a type modifier, not a type. 
 So it's not really a base type of a type, and it can be applied to any 
 type in existance.  Not the same as specifying a base type.


 Base type and supertype are not to be confused. By base type I understand 
 you mean you actually type class Super{} and class Sub:Super{}. The 
 subtyping relation is more general and applies to any two types Super and 
 Sub that satisfy a number of constraints.

 That const(T) is a supertype of both T and invariant(T) is essential and 
 not happenstance. It enshrines the fact that you can always pass a T or an 
 invariant(T) into a function. The fact that there is no difference in 
 layout and that const is not assignable also means that arrays of const(T) 
 are supertypes of both arrays of T and invariant(T), with important 
 consequences.


 
 But a type invariant(T) is not a subtype of const(U).


Well I agree. I was just pointing out a minute fact.


 How do you solve this 
 problem:
 
 class U
 {
    private T field
    public T property() { return field;}
    public invariant(T) property() { return field; } invariant;
    public const(T) property() {return field; } const;
 }
 
 Because T is completely unrelated to U, so the inout contract only has to do 
 with constancy, not the types.


Yah, that's where the PassQual template is needed. I'd agree without joy 
that, if handling true equivariance is too unwieldy, we can resign to 
solving only equivariance in qualifier.


Andrei
Oct 14 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Yah, that's where the PassQual template is needed. I'd agree without joy 
 that, if handling true equivariance is too unwieldy, we can resign to 
 solving only equivariance in qualifier.


FWIW, people have done without type eqivariance w/o complaint since 
static typing was invented. People have been complaining about const 
equivariance since at least C++ and D makes it worse.
Oct 14 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Oct 2008 01:18:40 +0400, Robert Fraser  
<fraserofthenight gmail.com> wrote:


 Andrei Alexandrescu wrote:

 Yah, that's where the PassQual template is needed. I'd agree without  
 joy that, if handling true equivariance is too unwieldy, we can resign  
 to solving only equivariance in qualifier.


 FWIW, people have done without type eqivariance w/o complaint since  
 static typing was invented. People have been complaining about const  
 equivariance since at least C++ and D makes it worse.


People didn't complain that they were nude until someone discovered it :)
I mean, human needs grow over time as they discover something useful.
Oct 14 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 15, 2008 at 6:23 AM, Denis Koroskin <2korden gmail.com> wrote:

 On Wed, 15 Oct 2008 01:18:40 +0400, Robert Fraser
 <fraserofthenight gmail.com> wrote:


 Andrei Alexandrescu wrote:

 Yah, that's where the PassQual template is needed. I'd agree without joy
 that, if handling true equivariance is too unwieldy, we can resign to
 solving only equivariance in qualifier.


 FWIW, people have done without type eqivariance w/o complaint since static
 typing was invented. People have been complaining about const equivariance
 since at least C++ and D makes it worse.


 People didn't complain that they were nude until someone discovered it :)
 I mean, human needs grow over time as they discover something useful.


Agreed.  There are uses for equivariance if you have it.
I think especially so when thinking about functional style programming
where you are chaining many functions together.  It's nice if the
chain you create doesn't lose the input object's true most derived
identity.  You can fake it with templates if you really have to, but
then if they are member functions they become non-virtual.

--bb
Oct 14 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, Oct 15, 2008 at 6:23 AM, Denis Koroskin <2korden gmail.com> wrote:

 On Wed, 15 Oct 2008 01:18:40 +0400, Robert Fraser
 <fraserofthenight gmail.com> wrote:


 Andrei Alexandrescu wrote:

 Yah, that's where the PassQual template is needed. I'd agree without joy
 that, if handling true equivariance is too unwieldy, we can resign to
 solving only equivariance in qualifier.


 FWIW, people have done without type eqivariance w/o complaint since static
 typing was invented. People have been complaining about const equivariance
 since at least C++ and D makes it worse.


 People didn't complain that they were nude until someone discovered it :)
 I mean, human needs grow over time as they discover something useful.


 
 Agreed.  There are uses for equivariance if you have it.
 I think especially so when thinking about functional style programming
 where you are chaining many functions together.  It's nice if the
 chain you create doesn't lose the input object's true most derived
 identity.  You can fake it with templates if you really have to, but
 then if they are member functions they become non-virtual.



Yah. What's the name of the feature? I was told a couple of times; I 
always forget it.

Andrei
Oct 14 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
I'm looking at all these funky syntaxes with their many unusual
implicit assumptions that they require a user to keep in mind, and
thinking it would all be a lot simpler if you could just declare some
template-like meta-variables in a preamble to the function.

I also don't like the looks of using a symbol in the return type that
doesn't get declared till you see the parameter list.

So how about introducing a "typedef block" where you can introduce
metatypes and give them constraints.

For constness:

typedef {  Const : const }  // in this case means any kind of const
Const(int) someFunc(Const(int) z) { ... }

For Objects:

class BaseClass {}
class DerivedClass : BaseClass {}

typedef { DType : BaseClass } // DType is anything passing  is(DType :
BaseClass)
DType someFunc(DType input)

For both:

typedef {
  DType : BaseClass;
  Const : const
}
Const(DType) someFunc(Const(DType) input)

And with something like this you can also come up with some solution
to the min problem
typedef{
   ConstA : const;
   ConstB : const;
   ConstC = maxConst!(ConstA,ConstB)
}
ConstC(Type) max(ConstA(Type), ConstB(Type))

maxConst would be some template-like thing func to take the "more
const" of the two qualifiers.  Not sure how you'd implement that.

Lots o hole's there, but the basic idea I'm suggesting is to declare
the types and qualifiers that can vary in some sort of a preamble
block.  To me this looks like it will be much more readable and easier
to maintain than any of these funky syntaxes with lots of implicit
rules to remember.

--bb
Oct 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote

 I'm looking at all these funky syntaxes with their many unusual
 implicit assumptions that they require a user to keep in mind, and
 thinking it would all be a lot simpler if you could just declare some
 template-like meta-variables in a preamble to the function.

 I also don't like the looks of using a symbol in the return type that
 doesn't get declared till you see the parameter list.

 So how about introducing a "typedef block" where you can introduce
 metatypes and give them constraints.

 For constness:

 typedef {  Const : const }  // in this case means any kind of const
 Const(int) someFunc(Const(int) z) { ... }

 For Objects:

 class BaseClass {}
 class DerivedClass : BaseClass {}

 typedef { DType : BaseClass } // DType is anything passing  is(DType :
 BaseClass)
 DType someFunc(DType input)

 For both:

 typedef {
  DType : BaseClass;
  Const : const
 }
 Const(DType) someFunc(Const(DType) input)

 And with something like this you can also come up with some solution
 to the min problem
 typedef{
   ConstA : const;
   ConstB : const;
   ConstC = maxConst!(ConstA,ConstB)
 }
 ConstC(Type) max(ConstA(Type), ConstB(Type))

 maxConst would be some template-like thing func to take the "more
 const" of the two qualifiers.  Not sure how you'd implement that.

 Lots o hole's there, but the basic idea I'm suggesting is to declare
 the types and qualifiers that can vary in some sort of a preamble
 block.  To me this looks like it will be much more readable and easier
 to maintain than any of these funky syntaxes with lots of implicit
 rules to remember.


I'm not a fan of complexity where it is not required.

You have outlined pretty much exactly the only use cases for this feature. 
So why do you want to continually write large typedefs that are identical in 
front of all your functions, when you can do so with a succinct syntax?

To put the use cases in more english descriptions:

1. I want the constancy of my return to be dependent on the constancy of the 
argument at the call site.
2. I want the constancy of my return to be the greatest common constancy of 
multiple arguments at the call site.
3. The return type will be exactly the same value that I passed in to the 
function, so I can use it for call chaining.  So it's OK to auto cast to the 
most derived type.
4. I want 1 and 3

Where greatest common constancy is defined as const if any arguments differ 
in constancy.  If they don't differ it is defined as the constancy of the 
arguments.

My biggest concern is 1 and 2, since otherwise for 1, we are left with 3 
different versions of the same function, and for 2, we are left with 3^n 
different versions.

3 (and 4) are of mild concern, because you are only forced to redefine once 
per class, and it's not as common a problem, since not all classes require 
handling of call chaining, whereas all classes should be const-aware.

I'll reiterate my proposal:

inout(X) f(inout(Y) y, inout(Z) z)

where inout means 'the greatest common constancy of all variables that are 
declared inout'.  Again, not in love with inout, but inout kind of reads 
'you get out what you put in', and it is a 'free' keyword.

and for 3:

X f(return X x);

where return means 'this function will return x'.  The return statements in 
this function are all required to return the value of x.  (x cannot be 
rebindable inside the function).

-Steve
Oct 14 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 I'll reiterate my proposal:
 
 inout(X) f(inout(Y) y, inout(Z) z)
 
 where inout means 'the greatest common constancy of all variables that are 
 declared inout'.  Again, not in love with inout, but inout kind of reads 
 'you get out what you put in', and it is a 'free' keyword.


Ugh. This doesn't quite work because it mimics the "true" solution (= 
bind an alias to the qualifier) by always calling that alias "inout" or 
whatever keyword name. This problem becomes apparent when you try to 
nest declarations:

inout(X) fun(inout(Y) function(inout(Z)) gun);

Now you tell me which inout goes where.


 and for 3:
 
 X f(return X x);
 
 where return means 'this function will return x'.  The return statements in 
 this function are all required to return the value of x.  (x cannot be 
 rebindable inside the function).


I think this is a bit too particular and too restrictive to be useful. 
Maybe we can all be happy with whatever solution we find for the general 
case. It's not that much to type afterall.


Andrei
Oct 14 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 15, 2008 at 11:02 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:

 I'll reiterate my proposal:

 inout(X) f(inout(Y) y, inout(Z) z)

 where inout means 'the greatest common constancy of all variables that are
 declared inout'.  Again, not in love with inout, but inout kind of reads
 'you get out what you put in', and it is a 'free' keyword.


 Ugh. This doesn't quite work because it mimics the "true" solution (= bind
 an alias to the qualifier) by always calling that alias "inout" or whatever
 keyword name. This problem becomes apparent when you try to nest
 declarations:

 inout(X) fun(inout(Y) function(inout(Z)) gun);

 Now you tell me which inout goes where.


Ew.  Yeh, that is sticky.  This will not be that common though.  Maybe
you could allow arguments/indexes on the inout for those cases?

  inout[0](X) fun(inout[0](Y) function(inout[1](Z)) gun);



 and for 3:

 X f(return X x);

 where return means 'this function will return x'.  The return statements
 in this function are all required to return the value of x.  (x cannot be
 rebindable inside the function).


 I think this is a bit too particular and too restrictive to be useful. Maybe
 we can all be happy with whatever solution we find for the general case.
 It's not that much to type afterall.


So what's the use case you have in mind that that doesn't satisfy?

--bb
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, Oct 15, 2008 at 11:02 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 inout(X) fun(inout(Y) function(inout(Z)) gun);

 Now you tell me which inout goes where.


 
 Ew.  Yeh, that is sticky.  This will not be that common though.  Maybe
 you could allow arguments/indexes on the inout for those cases?
 
   inout[0](X) fun(inout[0](Y) function(inout[1](Z)) gun);


If you'd ask for my opinion, I'd say the show of inout stops here.


 and for 3:

 X f(return X x);

 where return means 'this function will return x'.  The return statements
 in this function are all required to return the value of x.  (x cannot be
 rebindable inside the function).


 I think this is a bit too particular and too restrictive to be useful. Maybe
 we can all be happy with whatever solution we find for the general case.
 It's not that much to type afterall.


 
 So what's the use case you have in mind that that doesn't satisfy?


Too many. I mean most all. Essentially you can only implement identity 
and min/max :o). Think of stripl when you need to return a slice of the 
incoming argument.



Andrei
Oct 14 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 15, 2008 at 11:20 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Wed, Oct 15, 2008 at 11:02 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 inout(X) fun(inout(Y) function(inout(Z)) gun);

 Now you tell me which inout goes where.


 Ew.  Yeh, that is sticky.  This will not be that common though.  Maybe
 you could allow arguments/indexes on the inout for those cases?

  inout[0](X) fun(inout[0](Y) function(inout[1](Z)) gun);


 If you'd ask for my opinion, I'd say the show of inout stops here.


 and for 3:

 X f(return X x);

 where return means 'this function will return x'.  The return statements
 in this function are all required to return the value of x.  (x cannot
 be
 rebindable inside the function).


 I think this is a bit too particular and too restrictive to be useful.
 Maybe
 we can all be happy with whatever solution we find for the general case.
 It's not that much to type afterall.


 So what's the use case you have in mind that that doesn't satisfy?


 Too many. I mean most all. Essentially you can only implement identity and
 min/max :o). Think of stripl when you need to return a slice of the incoming
 argument.


But stripl just needs constness propagation, right?  So it's handled
by Steve's inout proposal.  The return thing just handles propagation
of base type.  I assume he has some way to combine inout with return
when you want to manipulate both constness and base type.

Maybe I've missed something though...

--bb
Oct 14 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 I'll reiterate my proposal:

 inout(X) f(inout(Y) y, inout(Z) z)

 where inout means 'the greatest common constancy of all variables that 
 are declared inout'.  Again, not in love with inout, but inout kind of 
 reads 'you get out what you put in', and it is a 'free' keyword.


 Ugh. This doesn't quite work because it mimics the "true" solution (= bind 
 an alias to the qualifier) by always calling that alias "inout" or 
 whatever keyword name. This problem becomes apparent when you try to nest 
 declarations:

 inout(X) fun(inout(Y) function(inout(Z)) gun);

 Now you tell me which inout goes where.


That would be invalid.  You need at least one inout argument that can be 
implicitly casted to const.  As far as I know that can't be done with a 
function pointer.

If you want to pass in a function pointer to a function which uses the inout 
constructs, then the inouts become literal inout.  i.e.:

inout(Y) foo(inout(Z) x) {...}

inout(X) fun(inout(Z) argtofoo, inout(Y) function(inout(Z)) gun) {...}

invariant(Z) z = cast(invariant) new Z;

auto x = fun(z, &foo);// x is of type invariant(X)

Maybe you had a different behavior in mind?


 and for 3:

 X f(return X x);

 where return means 'this function will return x'.  The return statements 
 in this function are all required to return the value of x.  (x cannot be 
 rebindable inside the function).


 I think this is a bit too particular and too restrictive to be useful. 
 Maybe we can all be happy with whatever solution we find for the general 
 case. It's not that much to type afterall.


I agree that the usefulness is not huge.  But there is no other compiler 
checkable way to guarantee that it can do the cast.  If the function in 
question doesn't know about the derived type, how can it generate a new 
instance that can be casted to the derived type?  It MUST return the exact 
argument.

The only possible other use is for typedefs, but if you are using typedefs, 
there isn't a huge incentive if you want to use them exactly like the base 
type.  And I don't want to define all functions in this style just in case 
someone has typedef'd the return type, and they want the compiler to 
auto-cast back to the typedef'd type.

I'll note that I can live without case 3, as the usefulness is low.

-Steve
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 I'll reiterate my proposal:

 inout(X) f(inout(Y) y, inout(Z) z)

 where inout means 'the greatest common constancy of all variables that 
 are declared inout'.  Again, not in love with inout, but inout kind of 
 reads 'you get out what you put in', and it is a 'free' keyword.


 Ugh. This doesn't quite work because it mimics the "true" solution (= bind 
 an alias to the qualifier) by always calling that alias "inout" or 
 whatever keyword name. This problem becomes apparent when you try to nest 
 declarations:

 inout(X) fun(inout(Y) function(inout(Z)) gun);

 Now you tell me which inout goes where.


 
 That would be invalid.  You need at least one inout argument that can be 
 implicitly casted to const.  As far as I know that can't be done with a 
 function pointer.
 
 If you want to pass in a function pointer to a function which uses the inout 
 constructs, then the inouts become literal inout.  i.e.:
 
 inout(Y) foo(inout(Z) x) {...}
 
 inout(X) fun(inout(Z) argtofoo, inout(Y) function(inout(Z)) gun) {...}
 
 invariant(Z) z = cast(invariant) new Z;
 
 auto x = fun(z, &foo);// x is of type invariant(X)
 
 Maybe you had a different behavior in mind?


Well this:

inout(X) fun(inout(Z) argtofoo, inout(Y) function(inout(Z)) gun) {...}

could mean two things:

1. "Bind all inout occurrences to a qualifier and resolve the signature", or

2. "Whenever inout occurs in a function parameter, don't bind it."

It's not that clear-cut which is the one to be chosen, and that will 
have to be a convention because the syntax is ambiguous.


Andrei
Oct 14 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 I'll reiterate my proposal:

 inout(X) f(inout(Y) y, inout(Z) z)

 where inout means 'the greatest common constancy of all variables that 
 are declared inout'.  Again, not in love with inout, but inout kind of 
 reads 'you get out what you put in', and it is a 'free' keyword.


 Ugh. This doesn't quite work because it mimics the "true" solution (= 
 bind an alias to the qualifier) by always calling that alias "inout" or 
 whatever keyword name. This problem becomes apparent when you try to 
 nest declarations:

 inout(X) fun(inout(Y) function(inout(Z)) gun);

 Now you tell me which inout goes where.


 That would be invalid.  You need at least one inout argument that can be 
 implicitly casted to const.  As far as I know that can't be done with a 
 function pointer.

 If you want to pass in a function pointer to a function which uses the 
 inout constructs, then the inouts become literal inout.  i.e.:

 inout(Y) foo(inout(Z) x) {...}

 inout(X) fun(inout(Z) argtofoo, inout(Y) function(inout(Z)) gun) {...}

 invariant(Z) z = cast(invariant) new Z;

 auto x = fun(z, &foo);// x is of type invariant(X)

 Maybe you had a different behavior in mind?


 Well this:

 inout(X) fun(inout(Z) argtofoo, inout(Y) function(inout(Z)) gun) {...}

 could mean two things:

 1. "Bind all inout occurrences to a qualifier and resolve the signature", 
 or

 2. "Whenever inout occurs in a function parameter, don't bind it."

 It's not that clear-cut which is the one to be chosen, and that will have 
 to be a convention because the syntax is ambiguous.


OK, how about this:

inout(Y) function(inout(Z)) f = &foo;
auto x = fun(z, f);

What is f?  Is this not the same as passing &foo directly?

-Steve
Oct 14 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 15, 2008 at 10:13 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:

 "Bill Baxter" wrote

 I'm looking at all these funky syntaxes with their many unusual
 implicit assumptions that they require a user to keep in mind, and
 thinking it would all be a lot simpler if you could just declare some
 template-like meta-variables in a preamble to the function.

 I also don't like the looks of using a symbol in the return type that
 doesn't get declared till you see the parameter list.

 So how about introducing a "typedef block" where you can introduce
 metatypes and give them constraints.

 For constness:

 typedef {  Const : const }  // in this case means any kind of const
 Const(int) someFunc(Const(int) z) { ... }

 For Objects:

 class BaseClass {}
 class DerivedClass : BaseClass {}

 typedef { DType : BaseClass } // DType is anything passing  is(DType :
 BaseClass)
 DType someFunc(DType input)

 For both:

 typedef {
  DType : BaseClass;
  Const : const
 }
 Const(DType) someFunc(Const(DType) input)

 And with something like this you can also come up with some solution
 to the min problem
 typedef{
   ConstA : const;
   ConstB : const;
   ConstC = maxConst!(ConstA,ConstB)
 }
 ConstC(Type) max(ConstA(Type), ConstB(Type))

 maxConst would be some template-like thing func to take the "more
 const" of the two qualifiers.  Not sure how you'd implement that.

 Lots o hole's there, but the basic idea I'm suggesting is to declare
 the types and qualifiers that can vary in some sort of a preamble
 block.  To me this looks like it will be much more readable and easier
 to maintain than any of these funky syntaxes with lots of implicit
 rules to remember.


 I'm not a fan of complexity where it is not required.

 You have outlined pretty much exactly the only use cases for this feature.
 So why do you want to continually write large typedefs that are identical in
 front of all your functions, when you can do so with a succinct syntax?


Think of it this way: right now to create variations on const you have
to declare the method three times.  This would reduce that to one
short preamble + one declaration.

And note that C++ gets along fine without any such assistance.  It is
far from "all your functions" that require such handling, that's why
it doesn't kill C++ not to have it.

For returning the input type, it has been commented "do we even really
need this?" since most other popular languages don't have such a
thing, and it is generally not a "buzz feature" you hear about much
(unlike closures or lambdas, etc).  So I don't think its use will be
that common, thus a little more verbose syntax will not be an undue
burden.  Indeed, precisely because it will not be used frequently, it
*should* have a more verbose, more explicit syntax.  So that on those
occasions when it is used it will A) not sneak past the casual
observer's notice and B) have at least some chance that the meaning of
the code can be guessed without having to look it up.


 To put the use cases in more english descriptions:

 1. I want the constancy of my return to be dependent on the constancy of the
 argument at the call site.
 2. I want the constancy of my return to be the greatest common constancy of
 multiple arguments at the call site.
 3. The return type will be exactly the same value that I passed in to the
 function, so I can use it for call chaining.  So it's OK to auto cast to the
 most derived type.
 4. I want 1 and 3

 Where greatest common constancy is defined as const if any arguments differ
 in constancy.  If they don't differ it is defined as the constancy of the
 arguments.

 My biggest concern is 1 and 2, since otherwise for 1, we are left with 3
 different versions of the same function, and for 2, we are left with 3^n
 different versions.

 3 (and 4) are of mild concern, because you are only forced to redefine once
 per class, and it's not as common a problem, since not all classes require
 handling of call chaining, whereas all classes should be const-aware.

 I'll reiterate my proposal:

 inout(X) f(inout(Y) y, inout(Z) z)

 where inout means 'the greatest common constancy of all variables that are
 declared inout'.  Again, not in love with inout, but inout kind of reads
 'you get out what you put in', and it is a 'free' keyword.

 and for 3:

 X f(return X x);

 where return means 'this function will return x'.  The return statements in
 this function are all required to return the value of x.  (x cannot be
 rebindable inside the function).


That does sound reasonable for the use cases you've outlined. I hadn't
realized you were making "inout" mean "maximal const".   I can't think
of any use case for non-maximal const of the top of my head so aside
from the "inout" being not a great word, I think I could live with
this ... unless someone discovers another use case.

If inout is useless now then we could retire it and add a new
"anyconst" keyword.  Or "vconst" for "variable/various/varying/virtual
const"

  vconst(X) f(vconst(Y) y, vconst(Z) z)

Or stick some syntax on it.  Like "const~", the squiggle indicating
"similar to".  Or "const?".

  const?(X) f(const?(Y) y, const?(Z) z);


---

Here's something that comes up -- iterators in C++ usually end up
needing to come in const and non-const flavors.  The "head" of both is
mutable, but the "tail" is const on the const flavor.  How do you
write this pair of functions as one?:

  const(X) getValue(const_iterator iter);
  X getValue(iterator iter);

I guess I can answer that myself.  If you wrote an apropriate
IterType!(T) template then maybe with your syntax you could say:

   inout(X) getValue(IterType!(inout(X)) iter);

and with my suggestion it would be something like

  typedef {Const : const }
  Const(X) getValue(IterType!(Const(X)) iter);

Ok, so I guess that's handled OK.

--bb
Oct 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter"wrote

 On Wed, Oct 15, 2008 at 10:13 AM, Steven Schveighoffer

 I'm not a fan of complexity where it is not required.

 You have outlined pretty much exactly the only use cases for this 
 feature.
 So why do you want to continually write large typedefs that are identical 
 in
 front of all your functions, when you can do so with a succinct syntax?


 Think of it this way: right now to create variations on const you have
 to declare the method three times.  This would reduce that to one
 short preamble + one declaration.


An example class with 10 accessors (forget about the implementations):

Your way:

class Owner
{
   typedef {  Const : const }
   Const(A) a() Const {...}

   typedef {  Const : const }
   Const(B) b() Const {...}

   typedef {  Const : const }
   Const(C) c() Const {...}

   typedef {  Const : const }
   Const(D) d() Const {...}

   typedef {  Const : const }
   Const(E) e() Const {...}

   typedef {  Const : const }
   Const(F) f() Const {...}

   typedef {  Const : const }
   Const(G) g() Const {...}

   typedef {  Const : const }
   Const(H) h() Const {...}

   typedef {  Const : const }
   Const(I) i() Const {...}

   // written by another author who prefers a different identifier for Const
   typedef {  Konst : const }
   Konst(J) j() Konst {...}
}

My way:

class Owner
{
   inout(A) a() inout {...}

   inout(B) b() inout{...}

   inout(C) c() inout{...}

   inout(D) d() inout{...}

   inout(E) e() inout{...}

   inout(F) f() inout{...}

   inout(G) g() inout{...}

   inout(H) h() inout{...}

   inout(I) i() inout{...}

   inout(J) j() inout{...}
}

It might be just me, but my way seems cleaner and easier to implement.


 And note that C++ gets along fine without any such assistance.  It is
 far from "all your functions" that require such handling, that's why
 it doesn't kill C++ not to have it.


But C++ doesn't have transitive const.  It is my experience that most C++ 
classes are not implemented as const-aware, or are but implemented const 
aware incorrectly.  Including classes I wrote.  I think Walter is right when 
he says that C++ const is a mess.


 For returning the input type, it has been commented "do we even really
 need this?" since most other popular languages don't have such a
 thing, and it is generally not a "buzz feature" you hear about much
 (unlike closures or lambdas, etc).  So I don't think its use will be
 that common, thus a little more verbose syntax will not be an undue
 burden.  Indeed, precisely because it will not be used frequently, it
 *should* have a more verbose, more explicit syntax.  So that on those
 occasions when it is used it will A) not sneak past the casual
 observer's notice and B) have at least some chance that the meaning of
 the code can be guessed without having to look it up.


It is not something I really am pushing.  My main concern is the const 
variance.  Something like this makes const so much more appealing (remember, 
no other languages have tried transitive const).  However, with an 
additional feature that requires all derived classes to re-implement a 
function, this can be more useful than just 'return the input value'.  Think 
clone().

As far as requiring a clumsy syntax, especially where changing style is 
possible but has no real affect on the result (i.e. using Konst instead of 
Const), I don't see that as a benefit.


 To put the use cases in more english descriptions:

 1. I want the constancy of my return to be dependent on the constancy of 
 the
 argument at the call site.
 2. I want the constancy of my return to be the greatest common constancy 
 of
 multiple arguments at the call site.
 3. The return type will be exactly the same value that I passed in to the
 function, so I can use it for call chaining.  So it's OK to auto cast to 
 the
 most derived type.
 4. I want 1 and 3

 Where greatest common constancy is defined as const if any arguments 
 differ
 in constancy.  If they don't differ it is defined as the constancy of the
 arguments.

 My biggest concern is 1 and 2, since otherwise for 1, we are left with 3
 different versions of the same function, and for 2, we are left with 3^n
 different versions.

 3 (and 4) are of mild concern, because you are only forced to redefine 
 once
 per class, and it's not as common a problem, since not all classes 
 require
 handling of call chaining, whereas all classes should be const-aware.

 I'll reiterate my proposal:

 inout(X) f(inout(Y) y, inout(Z) z)

 where inout means 'the greatest common constancy of all variables that 
 are
 declared inout'.  Again, not in love with inout, but inout kind of reads
 'you get out what you put in', and it is a 'free' keyword.

 and for 3:

 X f(return X x);

 where return means 'this function will return x'.  The return statements 
 in
 this function are all required to return the value of x.  (x cannot be
 rebindable inside the function).


 That does sound reasonable for the use cases you've outlined. I hadn't
 realized you were making "inout" mean "maximal const".   I can't think
 of any use case for non-maximal const of the top of my head so aside
 from the "inout" being not a great word, I think I could live with
 this ... unless someone discovers another use case.


I'm not super fond of inout, but it allows not adding a new keyword.  Some 
view that as an essential part of this.


 If inout is useless now then we could retire it and add a new
 "anyconst" keyword.  Or "vconst" for "variable/various/varying/virtual
 const"

  vconst(X) f(vconst(Y) y, vconst(Z) z)

 Or stick some syntax on it.  Like "const~", the squiggle indicating
 "similar to".  Or "const?".

  const?(X) f(const?(Y) y, const?(Z) z);


All these sound like valid alternatives, I'd be fine with any of them.


 Here's something that comes up -- iterators in C++ usually end up
 needing to come in const and non-const flavors.  The "head" of both is
 mutable, but the "tail" is const on the const flavor.  How do you
 write this pair of functions as one?:


You can't cast an iterator to 'head const' (another nagging problem, but a 
separate one), so the only viable option is templates.

-Steve
Oct 15 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

  const?(X) f(const?(Y) y, const?(Z) z);


 
 All these sound like valid alternatives, I'd be fine with any of them.


The const? has been on the table. It is a fave of mine because it offers 
a consistent solution for a related issue - detecting lvalueness:

void foo(ref? Widget w);

This means foo should bind to a ref Widget if you pass it an lvalue, and 
to a Widget if offered an rvalue. There is precedent on using "x?" to 
mean an optional x in regexes, so I wouldn't be surprised if many 
figured what const? does when first seeing it.

One issue  have with const? is that it binds the behavior to const, 
thereby eliminating the chance of making things more general. Also the 
const? will have to do something NOT suggested by the notation, namely 
pass the invariant, if present, along.

Anyhow, I wanted to share one more thought. On the face of it, as 
someone already said, we DO have a solution to avoid code duplication: 
templates. Maybe a fertile direction to take would be to use regular 
template syntax and just let the compiler figure out that it can 
actually define only one function instead of three.

What I'm saying is that we're really trying to beat the compiler in the 
head until it understands that:

S stripl(S s) if (is(S : const(char)[]) { stmts }

really means to us:

char[] stripl(char[] s) { stmts }
const(char)[] stripl(const(char)[] s) { stmts }
invariant(char)[] stripl(invariant(char) s) if (is(S : const(char)[]) { 
stmts }

What if, instead of finding yet another notation for that simple fact, 
we actually used the "right" notation (it is right because it's already 
there!) and figure out whether the compiler can understand it?

I was about to post when I realized that that idea won't work prettily 
at all with member functions... sigh :o/


Andrei
Oct 15 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

  const?(X) f(const?(Y) y, const?(Z) z);


 All these sound like valid alternatives, I'd be fine with any of them.


 The const? has been on the table. It is a fave of mine because it offers a 
 consistent solution for a related issue - detecting lvalueness:

 void foo(ref? Widget w);

 This means foo should bind to a ref Widget if you pass it an lvalue, and 
 to a Widget if offered an rvalue. There is precedent on using "x?" to mean 
 an optional x in regexes, so I wouldn't be surprised if many figured what 
 const? does when first seeing it.

 One issue  have with const? is that it binds the behavior to const, 
 thereby eliminating the chance of making things more general. Also the 
 const? will have to do something NOT suggested by the notation, namely 
 pass the invariant, if present, along.


I've convinced myself at this point that the const piece has to be separate 
from the 'derived type' piece.  Both can be required separately, i.e. I want 
to allow variations to the constancy of a specific type, but not to 
derivative types.

Therefore, it makes the most sense to me to make each feature use a distinct 
syntax.  So I have no problem with this notation for the const variant.

As far as invariant, I think it is well established that people don't gripe 
or sing the praises of the const-invariant system, they generally refer to 
it as the const system.  I think it's already a defacto standard that const 
in D includes invariant.  They are clearly related.


 Anyhow, I wanted to share one more thought. On the face of it, as someone 
 already said, we DO have a solution to avoid code duplication: templates. 
 Maybe a fertile direction to take would be to use regular template syntax 
 and just let the compiler figure out that it can actually define only one 
 function instead of three.

 What I'm saying is that we're really trying to beat the compiler in the 
 head until it understands that:

 S stripl(S s) if (is(S : const(char)[]) { stmts }

 really means to us:

 char[] stripl(char[] s) { stmts }
 const(char)[] stripl(const(char)[] s) { stmts }
 invariant(char)[] stripl(invariant(char) s) if (is(S : const(char)[]) { 
 stmts }

 What if, instead of finding yet another notation for that simple fact, we 
 actually used the "right" notation (it is right because it's already 
 there!) and figure out whether the compiler can understand it?

 I was about to post when I realized that that idea won't work prettily at 
 all with member functions... sigh :o/


Yeah, that would be tough for functions you want to make virtual.  I think 
it needs to be required to be a single function implementation, not left up 
to the compiler.

-Steve
Oct 15 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 One issue  have with const? is that it binds the behavior to const, 
 thereby eliminating the chance of making things more general. Also the 
 const? will have to do something NOT suggested by the notation, namely 
 pass the invariant, if present, along.
 


invariant is just a flavor of const and we're not restricted to regexp notation.


 What I'm saying is that we're really trying to beat the compiler in the 
 head until it understands that:
 
 S stripl(S s) if (is(S : const(char)[]) { stmts }


try to template this
const?(X) fun(const?(Y) y);

One big difference between normal and templated functions is you can provide
only signature for normal function.
Is it safe to typecheck/instantiate templated function without body?
Oct 16 2008
parent reply ore-sama <spam here.lot> writes:
ore-sama Wrote:


 Andrei Alexandrescu Wrote:

 S stripl(S s) if (is(S : const(char)[]) { stmts }


 try to template this
 const?(X) fun(const?(Y) y);


just a thought:

class A{} class B{ A a; }
DeriveConst!(I,A) fun(I)(I b)
{
	return b.a;
}

unittest
{
	B m;
	fun(m);
	const B c;
	fun(c);
	invariant B i;
	invariant A a=fun(i);
}

template DeriveConst(A,B)
{
	static if(is(A==invariant))alias invariant(B) DeriveConst;
	else static if(is(A==const))alias const(B) DeriveConst;
	else alias B DeriveConst;
}
Oct 21 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
ore-sama wrote:

 ore-sama Wrote:
 

 Andrei Alexandrescu Wrote:

 S stripl(S s) if (is(S : const(char)[]) { stmts }


 try to template this
 const?(X) fun(const?(Y) y);


 
 just a thought:
 
 class A{} class B{ A a; }
 DeriveConst!(I,A) fun(I)(I b)
 {
 	return b.a;
 }
 
 unittest
 {
 	B m;
 	fun(m);
 	const B c;
 	fun(c);
 	invariant B i;
 	invariant A a=fun(i);
 }
 
 template DeriveConst(A,B)
 {
 	static if(is(A==invariant))alias invariant(B) DeriveConst;
 	else static if(is(A==const))alias const(B) DeriveConst;
 	else alias B DeriveConst;
 }


Yah that was discussed under the name of PassQual. One problem is 
defining a palatable syntax for member functions.

Andrei
Oct 21 2008
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:

 Anyhow, I wanted to share one more thought. On the face of it, as
 someone already said, we DO have a solution to avoid code duplication:
 templates. Maybe a fertile direction to take would be to use regular
 template syntax and just let the compiler figure out that it can
 actually define only one function instead of three.


here's a stab at a syntax similar to templates:

T func(x : const, y : const)(X x, Y y, const Z z);

in the above the return type T constancy is dependent on the constancy
of x and y. z is a "regular" const.
the idea is that X's *constancy* (not the entire type!) is subtype of
const.

here's a method:

class Klass {
    T met(this: const, y : const)(X x, Y y, const Z z);
}

generic min function would look like:
T min(T, x : const, y : const) (T x, T y) { ...}

what do you think?
Oct 16 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:

 
 What I'm saying is that we're really trying to beat the compiler in the 
 head until it understands that:
 
 S stripl(S s) if (is(S : const(char)[]) { stmts }
 
 really means to us:
 
 char[] stripl(char[] s) { stmts }
 const(char)[] stripl(const(char)[] s) { stmts }
 invariant(char)[] stripl(invariant(char) s) if (is(S : const(char)[]) { 
 stmts }
 
 What if, instead of finding yet another notation for that simple fact, 
 we actually used the "right" notation (it is right because it's already 
 there!) and figure out whether the compiler can understand it?
 
 I was about to post when I realized that that idea won't work prettily 
 at all with member functions... sigh :o/
 
 
 Andrei


Wouldn't work prettily with member functions because one can't 
parameterize on the actual 'this' argument, right?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:

 Andrei Alexandrescu wrote:

 What I'm saying is that we're really trying to beat the compiler in 
 the head until it understands that:

 S stripl(S s) if (is(S : const(char)[]) { stmts }

 really means to us:

 char[] stripl(char[] s) { stmts }
 const(char)[] stripl(const(char)[] s) { stmts }
 invariant(char)[] stripl(invariant(char) s) if (is(S : const(char)[]) 
 { stmts }

 What if, instead of finding yet another notation for that simple fact, 
 we actually used the "right" notation (it is right because it's 
 already there!) and figure out whether the compiler can understand it?

 I was about to post when I realized that that idea won't work prettily 
 at all with member functions... sigh :o/


 Andrei


 
 Wouldn't work prettily with member functions because one can't 
 parameterize on the actual 'this' argument, right?


Yah, one can't do that unless more notation is added...

Andrei
Oct 18 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 16, 2008 at 12:46 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:

 "Bill Baxter"wrote

 On Wed, Oct 15, 2008 at 10:13 AM, Steven Schveighoffer

 I'm not a fan of complexity where it is not required.

 You have outlined pretty much exactly the only use cases for this
 feature.
 So why do you want to continually write large typedefs that are identical
 in
 front of all your functions, when you can do so with a succinct syntax?


 Think of it this way: right now to create variations on const you have
 to declare the method three times.  This would reduce that to one
 short preamble + one declaration.


 An example class with 10 accessors (forget about the implementations):

 Your way:

 class Owner
 {
   typedef {  Const : const }
   Const(A) a() Const {...}

   [...]

   // written by another author who prefers a different identifier for Const
   typedef {  Konst : const }
   Konst(J) j() Konst {...}
 }

 My way:

 class Owner
 {
   inout(A) a() inout {...}

   [...]
 }

 It might be just me, but my way seems cleaner and easier to implement.


Good example.
Definitely seems easier to implement.  And agreed that for common
cases it has less clutter.

I could suggest making some class-scoped version of the typedef{Const
: const} thing, but at that point it would just become a different
name for your "inout", and would have the disadvantage of different
people giving different names to something that will be used in just
about every class.

Hmmm, looking at this:

class Owner
{
  const?(A) a() const?{...}
  const?(B) b() const?{...}
  const?(C) c() const?{...}
  const?(D) d() const?{...}
  const?(E) e() const?{...}
  const?(F) f() const?{...}
  const?(G) g() const?{...}
  const?(H) h() const?{...}
  const?(I) i() const?{...}
  const?(J) j() const?{...}
}

makes me think if we go with that syntax, Andrei is sooner or later
going to complain about his D code asking him too many questions.  :-)
Eh, I guess he can edit the emacs mode to display const? as
smiley-faces or something.  :-) :-)


 Here's something that comes up -- iterators in C++ usually end up
 needing to come in const and non-const flavors.  The "head" of both is
 mutable, but the "tail" is const on the const flavor.  How do you
 write this pair of functions as one?:


 You can't cast an iterator to 'head const' (another nagging problem, but a
 separate one), so the only viable option is templates.


I don't understand this comment.  Why would you need to cast iterators
to "head const"?  I think head const is not supported by the current
const design at all -- via casting or otherwise.

--bb
Oct 15 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote

 On Thu, Oct 16, 2008 at 12:46 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 "Bill Baxter"wrote

 On Wed, Oct 15, 2008 at 10:13 AM, Steven Schveighoffer

 I'm not a fan of complexity where it is not required.

 You have outlined pretty much exactly the only use cases for this
 feature.
 So why do you want to continually write large typedefs that are 
 identical
 in
 front of all your functions, when you can do so with a succinct syntax?


 Think of it this way: right now to create variations on const you have
 to declare the method three times.  This would reduce that to one
 short preamble + one declaration.


 An example class with 10 accessors (forget about the implementations):

 Your way:

 class Owner
 {
   typedef {  Const : const }
   Const(A) a() Const {...}

   [...]

   // written by another author who prefers a different identifier for 
 Const
   typedef {  Konst : const }
   Konst(J) j() Konst {...}
 }

 My way:

 class Owner
 {
   inout(A) a() inout {...}

   [...]
 }

 It might be just me, but my way seems cleaner and easier to implement.


 Good example.
 Definitely seems easier to implement.  And agreed that for common
 cases it has less clutter.

 I could suggest making some class-scoped version of the typedef{Const
 : const} thing, but at that point it would just become a different
 name for your "inout", and would have the disadvantage of different
 people giving different names to something that will be used in just
 about every class.

 Hmmm, looking at this:

 class Owner
 {
  const?(A) a() const?{...}
  const?(B) b() const?{...}
  const?(C) c() const?{...}
  const?(D) d() const?{...}
  const?(E) e() const?{...}
  const?(F) f() const?{...}
  const?(G) g() const?{...}
  const?(H) h() const?{...}
  const?(I) i() const?{...}
  const?(J) j() const?{...}
 }

 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


lol!

or should I say lol?

I'm pretty sure this isn't taken:

const!(x)

and his emacs module could translate it to:

const <<x>>

(Yes, I have no idea how to type those weird characters ;)


 Here's something that comes up -- iterators in C++ usually end up
 needing to come in const and non-const flavors.  The "head" of both is
 mutable, but the "tail" is const on the const flavor.  How do you
 write this pair of functions as one?:


 You can't cast an iterator to 'head const' (another nagging problem, but 
 a
 separate one), so the only viable option is templates.


 I don't understand this comment.  Why would you need to cast iterators
 to "head const"?  I think head const is not supported by the current
 const design at all -- via casting or otherwise.


Damn!  I always do that!

swap head const with tail const, sorry ;)

-Steve
Oct 15 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Hmmm, looking at this:
 
 class Owner
 {
   const?(A) a() const?{...}
   const?(B) b() const?{...}
   const?(C) c() const?{...}
   const?(D) d() const?{...}
   const?(E) e() const?{...}
   const?(F) f() const?{...}
   const?(G) g() const?{...}
   const?(H) h() const?{...}
   const?(I) i() const?{...}
   const?(J) j() const?{...}
 }
 
 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


At this point Walter will intervene with:

class Owner
{
    const?
    {
       A  a()  {...}
       B  b()  {...}
       C  c()  {...}
       D  d()  {...}
       E  e()  {...}
       F  f()  {...}
       G  g()  {...}
       H  h()  {...}
       I  i()  {...}
       J  j()  {...}
    }
}

which isn't half bad.


Andrei
Oct 15 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 Hmmm, looking at this:

 class Owner
 {
   const?(A) a() const?{...}
   const?(B) b() const?{...}
   const?(C) c() const?{...}
   const?(D) d() const?{...}
   const?(E) e() const?{...}
   const?(F) f() const?{...}
   const?(G) g() const?{...}
   const?(H) h() const?{...}
   const?(I) i() const?{...}
   const?(J) j() const?{...}
 }

 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


 
 At this point Walter will intervene with:
 
 class Owner
 {
    const?
    {
       A  a()  {...}
       B  b()  {...}
       C  c()  {...}
       D  d()  {...}
       E  e()  {...}
       F  f()  {...}
       G  g()  {...}
       H  h()  {...}
       I  i()  {...}
       J  j()  {...}
    }
 }
 
 which isn't half bad.
 
 
 Andrei


Huh? But

   class Owner {
     const    // without the “?”
     {
       A  a()  {...}
       B  b()  {...}
       C  c()  {...}
       D  d()  {...}
       E  e()  {...}
       F  f()  {...}
       G  g()  {...}
       H  h()  {...}
       I  i()  {...}
       J  j()  {...}
     }
   }

only apply const on the function, but not their return type (i.e. they 
become

       A a() const { ... }
       // etc.

but not

       const(A) a() const { ... }
       // etc.

)
Oct 15 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 Hmmm, looking at this:

 class Owner
 {
   const?(A) a() const?{...}
   const?(B) b() const?{...}
   const?(C) c() const?{...}
   const?(D) d() const?{...}
   const?(E) e() const?{...}
   const?(F) f() const?{...}
   const?(G) g() const?{...}
   const?(H) h() const?{...}
   const?(I) i() const?{...}
   const?(J) j() const?{...}
 }

 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


 At this point Walter will intervene with:

 class Owner
 {
    const?
    {
       A  a()  {...}
       B  b()  {...}
       C  c()  {...}
       D  d()  {...}
       E  e()  {...}
       F  f()  {...}
       G  g()  {...}
       H  h()  {...}
       I  i()  {...}
       J  j()  {...}
    }
 }

 which isn't half bad.


 Andrei


 
 Huh? But
 
   class Owner {
     const    // without the “?”
     {
       A  a()  {...}
       B  b()  {...}
       C  c()  {...}
       D  d()  {...}
       E  e()  {...}
       F  f()  {...}
       G  g()  {...}
       H  h()  {...}
       I  i()  {...}
       J  j()  {...}
     }
   }
 
 only apply const on the function, but not their return type (i.e. they 
 become
 
       A a() const { ... }
       // etc.
 
 but not
 
       const(A) a() const { ... }
       // etc.
 
 )


Yah, but it does not make sense to not apply const? to the return value.

Andrei
Oct 15 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 Hmmm, looking at this:

 class Owner
 {
   const?(A) a() const?{...}
   const?(B) b() const?{...}
   const?(C) c() const?{...}
   const?(D) d() const?{...}
   const?(E) e() const?{...}
   const?(F) f() const?{...}
   const?(G) g() const?{...}
   const?(H) h() const?{...}
   const?(I) i() const?{...}
   const?(J) j() const?{...}
 }

 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


 At this point Walter will intervene with:

 class Owner
 {
    const?
    {
       A  a()  {...}
       B  b()  {...}
       C  c()  {...}
       D  d()  {...}
       E  e()  {...}
       F  f()  {...}
       G  g()  {...}
       H  h()  {...}
       I  i()  {...}
       J  j()  {...}
    }
 }

 which isn't half bad.


 Andrei


 Huh? But

   class Owner {
     const    // without the "?"
     {
       A  a()  {...}
       B  b()  {...}
       C  c()  {...}
       D  d()  {...}
       E  e()  {...}
       F  f()  {...}
       G  g()  {...}
       H  h()  {...}
       I  i()  {...}
       J  j()  {...}
     }
   }

 only apply const on the function, but not their return type (i.e. they 
 become

       A a() const { ... }
       // etc.

 but not

       const(A) a() const { ... }
       // etc.

 )


 Yah, but it does not make sense to not apply const? to the return value.


compromise:


 class Owner
 {
    const?
    {
       const?(A)  a()  {...}
       const?(B)  b()  {...}
       const?(C)  c()  {...}
       const?(D)  d()  {...}
       const?(E)  e()  {...}
       const?(F)  f()  {...}
       const?(G)  g()  {...}
       const?(H)  h()  {...}
       const?(I)  i()  {...}
      const?(J)  j()  {...}
    }
 }






Also still not terrible.  Whatever we come up with should be consistent with 
the other type modifiers.

Otherwise, you get into sticky situations like this:

const?
{
   A a(X x)
}

Should this translate to:

const?(A) a(const?(X) x) const?

Sidenote: seeing that const? at the end really looks weird.  Not sure I like 
this so much any more.  I think I'd rather see a new keyword...

-Steve
Oct 15 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 16, 2008 at 4:10 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 Hmmm, looking at this:

 class Owner
 {
  const?(A) a() const?{...}
  const?(B) b() const?{...}
  const?(C) c() const?{...}
  const?(D) d() const?{...}
  const?(E) e() const?{...}
  const?(F) f() const?{...}
  const?(G) g() const?{...}
  const?(H) h() const?{...}
  const?(I) i() const?{...}
  const?(J) j() const?{...}
 }

 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


 At this point Walter will intervene with:

 class Owner
 {
   const?
   {
      A  a()  {...}
      B  b()  {...}
      C  c()  {...}
      D  d()  {...}
      E  e()  {...}
      F  f()  {...}
      G  g()  {...}
      H  h()  {...}
      I  i()  {...}
      J  j()  {...}
   }
 }

 which isn't half bad.


I was thinking about that too.  But I'm not a big fan of blocks that
change the meaning of declarations in a non-local way.  It looks quite
readable in toy examples, but after you insert all the bodies and
documentation comments for everything in the block, it becomes very
easy to lose sight of the tag way back at the beginning of the block.

--bb
Oct 15 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Thu, Oct 16, 2008 at 4:10 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 Hmmm, looking at this:

 class Owner
 {
  const?(A) a() const?{...}
  const?(B) b() const?{...}
  const?(C) c() const?{...}
  const?(D) d() const?{...}
  const?(E) e() const?{...}
  const?(F) f() const?{...}
  const?(G) g() const?{...}
  const?(H) h() const?{...}
  const?(I) i() const?{...}
  const?(J) j() const?{...}
 }

 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


 At this point Walter will intervene with:

 class Owner
 {
   const?
   {
      A  a()  {...}
      B  b()  {...}
      C  c()  {...}
      D  d()  {...}
      E  e()  {...}
      F  f()  {...}
      G  g()  {...}
      H  h()  {...}
      I  i()  {...}
      J  j()  {...}
   }
 }

 which isn't half bad.


 
 I was thinking about that too.  But I'm not a big fan of blocks that
 change the meaning of declarations in a non-local way.  It looks quite
 readable in toy examples, but after you insert all the bodies and
 documentation comments for everything in the block, it becomes very
 easy to lose sight of the tag way back at the beginning of the block.


I disagree. A block is a block is a block. Indentation shows it's not 
non-local. I understand how you could formulate an argument against 
labels. They do change meaning in a non-obvious way. Block indentation 
makes all the difference. I'm in fact surprised to hear that from a 
pythonboi :o).

Andrei
Oct 15 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 16, 2008 at 4:39 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Thu, Oct 16, 2008 at 4:10 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 Hmmm, looking at this:

 class Owner
 {
  const?(A) a() const?{...}
  const?(B) b() const?{...}
  const?(C) c() const?{...}
  const?(D) d() const?{...}
  const?(E) e() const?{...}
  const?(F) f() const?{...}
  const?(G) g() const?{...}
  const?(H) h() const?{...}
  const?(I) i() const?{...}
  const?(J) j() const?{...}
 }

 makes me think if we go with that syntax, Andrei is sooner or later
 going to complain about his D code asking him too many questions.  :-)
 Eh, I guess he can edit the emacs mode to display const? as
 smiley-faces or something.  :-) :-)


 At this point Walter will intervene with:

 class Owner
 {
  const?
  {
     A  a()  {...}
     B  b()  {...}
     C  c()  {...}
     D  d()  {...}
     E  e()  {...}
     F  f()  {...}
     G  g()  {...}
     H  h()  {...}
     I  i()  {...}
     J  j()  {...}
  }
 }

 which isn't half bad.


 I was thinking about that too.  But I'm not a big fan of blocks that
 change the meaning of declarations in a non-local way.  It looks quite
 readable in toy examples, but after you insert all the bodies and
 documentation comments for everything in the block, it becomes very
 easy to lose sight of the tag way back at the beginning of the block.


 I disagree. A block is a block is a block. Indentation shows it's not
 non-local. I understand how you could formulate an argument against labels.
 They do change meaning in a non-obvious way. Block indentation makes all the
 difference. I'm in fact surprised to hear that from a pythonboi :o).


If the top of the block is off the screen it's not necessarily obvious
that it's a block.
And even if you do realize it's a block, you don't know what special
attributes are in play without scrolling back up to see what it says.
That's why I don't like em.  Not sure what Python has to do with it.
I think a method signature in Python can pretty much always be read
and understood without having to look at some tag that exists further
up the screen.  Closest thing I can think of in Python is the
decorators, but I think those always have to appear right before the
method signature that they modify.

--bb
Oct 15 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 If the top of the block is off the screen it's not necessarily obvious
 that it's a block.


By the same argument it's not obvious whether you're in a class, 
function, template etc. definition. All of them do change the context of 
what's going on.

Andrei
Oct 15 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 16, 2008 at 5:57 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 If the top of the block is off the screen it's not necessarily obvious
 that it's a block.


 By the same argument it's not obvious whether you're in a class, function,
 template etc. definition. All of them do change the context of what's going
 on.


The fact that I have to keep one thing in mind does not make an excuse
for creating several other things I also have to keep in mind.
I've heard the human mind can keep about 7 or 8 things active at once.
 It's a limited number.  So the more info you can keep local the
better.  Same reason we don't declare all our variables at the tops of
functions any more.  Declaration at the point of use makes the type
more readily available at the point in the code where you need to know
it.

Anyway, I've got no problem with collecting things in attribute blocks
like that, as long as the blocks stay less than roughly a page in
length.
Similar to the commonly use rule of thumb for function length.

--bb
Oct 15 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 15, 2008 at 9:27 AM, Bill Baxter <wbaxter gmail.com> wrote:

 I'm looking at all these funky syntaxes with their many unusual
 implicit assumptions that they require a user to keep in mind, and
 thinking it would all be a lot simpler if you could just declare some
 template-like meta-variables in a preamble to the function.

 I also don't like the looks of using a symbol in the return type that
 doesn't get declared till you see the parameter list.

 So how about introducing a "typedef block" where you can introduce
 metatypes and give them constraints.

 For constness:

 typedef {  Const : const }  // in this case means any kind of const
 Const(int) someFunc(Const(int) z) { ... }

 For Objects:

 class BaseClass {}
 class DerivedClass : BaseClass {}

 typedef { DType : BaseClass } // DType is anything passing  is(DType :
 BaseClass)
 DType someFunc(DType input)

 For both:

 typedef {
  DType : BaseClass;
  Const : const
 }
 Const(DType) someFunc(Const(DType) input)

 And with something like this you can also come up with some solution
 to the min problem
 typedef{
   ConstA : const;
   ConstB : const;
   ConstC = maxConst!(ConstA,ConstB)
 }
 ConstC(Type) max(ConstA(Type), ConstB(Type))

 maxConst would be some template-like thing func to take the "more
 const" of the two qualifiers.  Not sure how you'd implement that.

 Lots o hole's there, but the basic idea I'm suggesting is to declare
 the types and qualifiers that can vary in some sort of a preamble
 block.  To me this looks like it will be much more readable and easier
 to maintain than any of these funky syntaxes with lots of implicit
 rules to remember.


Actually, let me take a step back from any concrete syntax.  What I
think would be an easy-to-read and easy-to-use system would look like
this in pseudocode:

  let "Const" be any kind of constness
  let "BType" be any kind of object derived from BaseObject
  in the following declaration:
  Const(BType) theFunction(Const(BType) x, string y) { ... }

In other words, *first* explicitly give names to the things that will
vary, *then* use those names in the method signature.

I think this will be much easier to use and more flexible than making
up a bunch of rules with the aim of implying the same things via
subtle variations of the basic declaration syntax.

--bb
Oct 14 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 Andrei Alexandrescu wrote:

 Yah, that's where the PassQual template is needed. I'd agree without 
 joy that, if handling true equivariance is too unwieldy, we can resign 
 to solving only equivariance in qualifier.


 
 FWIW, people have done without type eqivariance w/o complaint since 
 static typing was invented. People have been complaining about const 
 equivariance since at least C++ and D makes it worse.


Well Scala, Eiffel and probably other languages have support for at 
least equivariance of the current object. I always forget the name of 
that feature.

Andrei
Oct 14 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Oct 2008 00:31:15 +0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 What about returning a member?  i.e.:

 inout(typeof(s.ptr)) getptr(inout const(char)[] s) { return s.ptr;}


 Yah there is a recurring problem - we need to find a notation that works
 nicely and expressively for member functions as well as free functions.

 For free functions an easy-to-explain-and-understand way is to have
 "inout" mark the incoming / outgoing TYPE entirely, not only its
 qualifier. Then:

 inout stripl(inout const(char)[] s);

 means: accept any subtype of const(char)[] and call that type "inout" in
 the return type. Then it's easy to access dependent stuff:

 typeof(inout.ptr) at(inout const(char)[] s);

 Notice that for one-parameter functions there's not even a need to  
 specify
 the inout in the argument list because it's unambiguous:

 inout stripl(const(char)[] s);
 typeof(inout.ptr) at(const(char)[] s);

 When you get into member functions things aren't quite nice:

 class A
 {
     private int a;
     inout clone() inout; // ehm
     typeof(&inout.a) getPtrToA() inout; // ehm
 }


 is that what you had in mind?

 this syntax is going to be used often, since it's what you would use  
 for
 an accessor.  So it should be simple to understand if possible.


 Yah I agree. At this point I don't have any solid solution for  
 notation...
 please continue rolling out ideas.


 Damn, I think there is some confusion here, because we are trying to  
 solve
 two related, but unequal problems.

 First is const equivariance (is that the right term?).  I want to  
 specify a
 function that treats an argument as const, but does not affect the const
 contract that the caller has with that argument (i.e. my original scoped
 const proposal).

 The second is type equivariance.  I want to specify that I will treat an
 argument as a base type, but I will not change the derived type that the
 caller is using.

 These are similar, if you consider that const is a 'base type' of its
 mutable or invariant version.  But there is one caveat that is hard to
 explain using this terminology.  const is a type modifier, not a type.   
 So
 it's not really a base type of a type, and it can be applied to any type  
 in
 existance.  Not the same as specifying a base type.

 So the first requirement (const equivariance) does not require that I  
 return
 a derivative of the argument, it requires that I return an argument that  
 is
 part of the input, but contains the same const contract as the passed in
 variable at the *call site*.  It does not require that the return type is
 derived from the input.

 It is this first requirement that is the only requirement necessary for
 functions which return unrelated types from their arguments.  i.e., for  
 an
 accessor, which is not returning something of the same type as its  
 argument,
 the only thing that is important to keep the same at the call site is the
 const modifiers.  For example, you can return a base type that is
 automatically converted to a derived type, but that must be accomplished
 with an overridden function.  That is already handled using covariance,  
 and
 I really don't think there is a way to enforce this in the compiler.

 An example, a linked list.

 class Link
 {
    private Link next;
    Link getNext() { return next;}
 }

 class DerivedLink : Link
 {
    int someExtraData;
 }

 We currently solve this by adding a covariant getNext() to DerivedLink.

 But would it be enough to just change the getNext function in the base  
 type
 to:

 inout getNext() { return next; } inout;

 I don't think it can be enforced.  Because some other Link function can  
 set
 next to another type of Link (possibly a base Link).  It is up to the
 designer of DerivedLink to ensure that next always points to a  
 descendent of
 DerivedLink.  In this case, I think it's a requirement to use covariant
 functions.

 However, it *would* be advantageous to declare getNext as not altering  
 the
 const contract of the caller.  That is, it returns the same constancy  
 that
 it is called with (in this example, inout implies const):

 inout(Link) getNext() { return next; } inout;

 For the second requirement, I can see value in things like call-chaining:

 class C
 {
   inout doSomething() inout { return this;}
 }

 class D : C
 {
    inout doSomethingElse() inout { return this;}
 }

 auto d = new D;
 d.doSomething().doSomethingElse();

 However, the return value MUST be exactly the same value as the input.   
 If
 it's only the same type, we lose all compiler enforcibility.

 So does it make sense to split these two requirements?

 I propose to use inout only to deal with const contracts, and use another
 syntax to signify which parameter will be returned:

 inout(X) foo(inout(Y) y); // X and Y are unrelated types

 a stab at 'returning this exact parameter'
 X foo(return X x); // The return value from foo will be x, so the  
 compiler
 is free to upcast automatically.

 inout(X) foo(return inout(X) x); // combination, signifies that I will
 return x, and I promise not to modify it in the function.

 With this scheme, I think possibly inout might not be as clear...

 -Steve


I think you brought very interesting topic with a second example!
However, I believe it may be solved easily. Let's start with your example:

class A
{
     final A foo() {
         // do something
         return this;
     }
}

class B : A
{
}

It is obvious that for any type B which is a subclass of A it is safe to  
do the following:

B b = ...;
b = cast(B)b.foo(); // this is guarantied to be safe

This, however, is only true if the foo() method is final (I talk about  
current D for now).

So you say, why not to allow this without casting by making some rules so  
that compiler could ensure code correctness. I believe this is possible  
and the method signature could be as Andrei proposed:

class A
{
     final typeof(this) foo() {
         // do something
         return this;
     }
}

This is consistent with the behaviour: return type is always covariant  
with the this type at callsite.

Once again, this operation is guarantied to be safe if method returns  
'this' and is final. But we want to take it one step forward! For example,  
we may want to make it virtual, not final. In this case we can lift the  
restriction to return this as well, subject to the following constrains:

1) Method may be made final if and only if it returns this.
2) If base class method is not final then the derived class have to  
override the method.
3) Class may return some other pointer, not only this, but it should  
statically check that the pointer type is covariant with this type.

Note1: Class could also be allowed to not override non-final method of the  
base class if it returns this (it is safe to do so). But this greatly  
increases checking rules complexity. In some cases body might not be  
available so compiler can't whether we return this and therefore are  
forced to override it anyway.

Note2: method that returns null might be also allowed to be final.

Let's put some more examples:

module example1;

class A
{
     final typeof(this) foo() { return this; }
}

class B  // ok
{
     void bar();
}

(new B()).foo().bar();

module example2;

class A
{
     final typeof(this) foo1(); // body is in some other file, guarantied  
to return this
     typeof(this) foo2();
}

class B
{
     typeof(this) foo2() { super.foo2(); return this; }
     void bar() {}
}

(new B()).foo2().foo1().bar();

module example3;

class Link
{
     typeof(this) next() {
         return _next; // ok, typeof(next) == typeof(this). Note that we  
can't make this method final
     }

     private Link _next;
}

class DerivedLink1 : Link
{
     int someExtraData; // fails to compile: class doesn't override  
typeof(this) next();
}

class DerivedLink2 : Link
{
     int someExtraData;
     typeof(this) next() {
         return cast(DerivedLink)super.next(); // ok, might return null
     }
}

auto data = (new DerivedLink2()).next().next().someExtraData;

module example4;

class A
{
     typeof(this) clone() {
         return new A(this); // note that we can't make this method final
     }
}

class B1 : A
{
     // fails to compile, *have to* override clone()
}

class B2 : A
{
     /*final*/ typeof(this) clone() {
         return null; // it's ok. But shall we allow final methods to  
return null?
     }
}

class B3 : A
{
     typeof(this) clone() {
         return new A(); // error, is (A : typeof(this)) is false
     }
}

class B4 : A
{
     typeof(this) clone() {
         return new B4();
     }

     void bar() {}
}

(new B4()).clone().clone().bar();

I think this may work.
Oct 14 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 14 Oct 2008 16:31:15 -0400,
Steven Schveighoffer wrote:

 Damn, I think there is some confusion here, because we are trying to solve 
 two related, but unequal problems.
 
 First is const equivariance (is that the right term?).  I want to specify a 
 function that treats an argument as const, but does not affect the const 
 contract that the caller has with that argument (i.e. my original scoped 
 const proposal).
 
 The second is type equivariance.  I want to specify that I will treat an 
 argument as a base type, but I will not change the derived type that the 
 caller is using.
 
 These are similar, if you consider that const is a 'base type' of its 
 mutable or invariant version.  But there is one caveat that is hard to 
 explain using this terminology.  const is a type modifier, not a type.  So 
 it's not really a base type of a type, and it can be applied to any type in 
 existance.  Not the same as specifying a base type.


This is a very good point.  I think these cases are different, too.  And 
I think there is another confusion which leads to obscure syntaxes.

Any function argument has two types: the call-site and the function-site, 
the latter is made from the former by an implicit cast.  You must specify 
function-site type for the function body to compile properly, and you 
want to know a call-site type for equi-trickery.

But that's not all.  An equi-function should have two return types: one 
function-site for the body to compile properly, and one call-site for the 
type system to work there.

Let's experiment with an explicit syntax.  I'll define a calltype() 
built-in function similar to typeof() but yielding a call-site type in a 
function definition context.  And I'll use cast() to specify the call-
site return type of a function.

cast(calltype(s)) const(char)[] stripl(const(char)[] s);

Here cast() explicitly defines this function as a variant function.

class A { cast(calltype(this)) A clone() { return new A; } }

Now a verbose one:

cast(PassQual!(calltype(a), calltype(b))(char)[])
  const(char)[] choose(const(char)[] a, const(char)[] b, bool which);

Now that I look at this, all the magic is concentrated within the cast() 
block and is actually quite close to Bill Baxter's typedef {} proposal.  
And it seems like the call-site types are only needed there, and they're 
the only types needed.  So typeof() can be used there with modified 
semantics.  I even think that inout() can be used instead of cast() with 
pretty much the same effect on readability.  So a simple covariant 
function would look like this:

inout(typeof(s)) const(char)[] foo(const(char)[] s)
{
  return s[1..$];
}

which is translated into:

T foo(T)(T s)
{
  return cast(T) _foo_impl(s);
}
const(char)[] _foo_impl(const(char)[] s)
{
  return s[1..$];
}

Though I'd prefer cast() or var() or covar() as a covariant modifier.
Oct 15 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sergey Gromov" wrote

 Tue, 14 Oct 2008 16:31:15 -0400,
 Steven Schveighoffer wrote:

 Damn, I think there is some confusion here, because we are trying to 
 solve
 two related, but unequal problems.

 First is const equivariance (is that the right term?).  I want to specify 
 a
 function that treats an argument as const, but does not affect the const
 contract that the caller has with that argument (i.e. my original scoped
 const proposal).

 The second is type equivariance.  I want to specify that I will treat an
 argument as a base type, but I will not change the derived type that the
 caller is using.

 These are similar, if you consider that const is a 'base type' of its
 mutable or invariant version.  But there is one caveat that is hard to
 explain using this terminology.  const is a type modifier, not a type. 
 So
 it's not really a base type of a type, and it can be applied to any type 
 in
 existance.  Not the same as specifying a base type.


 This is a very good point.  I think these cases are different, too.  And
 I think there is another confusion which leads to obscure syntaxes.

 Any function argument has two types: the call-site and the function-site,
 the latter is made from the former by an implicit cast.  You must specify
 function-site type for the function body to compile properly, and you
 want to know a call-site type for equi-trickery.

 But that's not all.  An equi-function should have two return types: one
 function-site for the body to compile properly, and one call-site for the
 type system to work there.

 Let's experiment with an explicit syntax.  I'll define a calltype()
 built-in function similar to typeof() but yielding a call-site type in a
 function definition context.  And I'll use cast() to specify the call-
 site return type of a function.

 cast(calltype(s)) const(char)[] stripl(const(char)[] s);

 Here cast() explicitly defines this function as a variant function.

 class A { cast(calltype(this)) A clone() { return new A; } }

 Now a verbose one:

 cast(PassQual!(calltype(a), calltype(b))(char)[])
  const(char)[] choose(const(char)[] a, const(char)[] b, bool which);

 Now that I look at this, all the magic is concentrated within the cast()
 block and is actually quite close to Bill Baxter's typedef {} proposal.
 And it seems like the call-site types are only needed there, and they're
 the only types needed.  So typeof() can be used there with modified
 semantics.  I even think that inout() can be used instead of cast() with
 pretty much the same effect on readability.  So a simple covariant
 function would look like this:

 inout(typeof(s)) const(char)[] foo(const(char)[] s)
 {
  return s[1..$];
 }

 which is translated into:

 T foo(T)(T s)
 {
  return cast(T) _foo_impl(s);
 }
 const(char)[] _foo_impl(const(char)[] s)
 {
  return s[1..$];
 }

 Though I'd prefer cast() or var() or covar() as a covariant modifier.


Auto-deducing the return type is only half the problem.

During the function, the compiler must make certain guarantees about s, and 
about the return type.  For example, something cannot be implicitly cast to 
the type of s, since its true type is not known at compile-time, only it's 
base type.  And since the return type must match the constancy of the input, 
the return type must be restricted to only the type of s.  Since you can't 
implicitly cast to s, you must return s or a subset of s.

But the return type doesn't necessarily have to be related to s, it could be 
just of the same constancy.  Someone asked, what if you are returning a 
private field (i.e. through an accessor).  Would you use 
typeof(this.privateField) in the signature?  Doesn't this expose some 
private field name?  What if there was no field that existed for the type 
you wanted to return?  You'd have to do kludgy stuff like typeof(T.init), 
but then how do you flag the argument as being const-variant?

I think we need something to flag the argument as const-variant, and 
something to flag the return value as const-variant.  It's clearer that the 
argument is being affected, and it's clearer what you want to return.  To 
me:

inout(char)[] stripl(inout(char)[] s);

is much clearer than

typeof(s) stripl(const(char)[] s);

I can look at each part of the signature, and know exactly what is going on. 
With the second syntax, everything has references to other pieces, so I have 
to look back and forth to see what is happening.  If s is buried in a long 
list of arguments, it's even less clear.

Note also that the typeof(T) syntax does not help functions with multiple 
arguments without template kludginess (and I can't see how the compiler 
enforces the guarantees, given a custom template), whereas using a builtin 
type modifier handles it perfectly.

At least for const-variance, a type modifier is ideal.  Some of the other 
ideas might benefit from a typeof (arg) syntax.

-Steve
Oct 15 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 One other syntax that Janice proposed (and I later put into a bugzilla), 
 is to use the dead keyword inout.  Meaning, what you send in is what you 
 get out.  ref already completely replaces inout, so there is no need to 
 keep it under its current meaning:

 inout(char)[] stripl(inout(char)[] s);

 I'm not in love with this completely, but it has the benefit of not 
 requiring a new keyword.


 Also I guess:

 class C
 {
     Range!(inout(C)) foo() inout;
 }

 And also:

 class Base {}
 class Derived : Base {}
 inout foo(inout Base b);

 I think this could work and doesn't look half bad. Of course, you'll be 
 tasked with addressing protests about yet another D1/D2 incompatibility. 
 :o)


One thing that should be mentioned, my original post implied that the 'base 
type' is implied to be const (since originally, this is the only problem I 
was trying to solve).

So in my example:

inout(char)[] stripl(inout(char)[] s);

s is implied to be const(char) during the function.  With your 
interpretation of inout meaning 'anything that is derived from', then I 
suppose the correct syntax should be:

inout(const(char))[] stripl(inout(const(char))[] s);

With your special trick of implying the return type looking like this:

inout[] stripl(inout(const(char))[] s);

Not as appealing, but it still works.

-Steve
Oct 14 2008
prev sibling next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 What do you think? I'm almost afraid to post this.


I vote "no" on the whole feature.

As far is I can tell, it doesn't add any new capabilities to the 
language, except for working around difficult corner cases in the cost 
system, and I think it's a mistake to add features whose sole purpose is 
to workaround the deficiencies in other features.

If the const system has holes in it, I vote for patching those holes by 
redesigning the const system, not by adding a workaround.

Or maybe I'm mistaken. Are there any compelling examples which don't 
revolve around constancy?

--benji
Oct 14 2008
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 12 Oct 2008 23:34:05 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Many functions return one of their parameters regardless of the way it  
 was qualified.

 char[] stripl(char[] s);
 const(char)[] stripl(const(char)[] s);
 invariant(char)[] stripl(invariant(char)[] s);

 Stripl is not a particularly good example because it needs to work on  
 wchar and dchar too, but let's ignore that aspect for now.

 There's been several proposals in this group on tackling that problem.

 In unrelated proposals and discussions, people mentioned the need for  
 functions that return the exact type of this:

 class A { A clone(); }
 class B : A { B clone(); }

 How can we declare A.clone such that all of its derived classes have it  
 return their own type?

 It took me a while to realize they are really very related. This is easy  
 to figure out if you think that invariant(char)[] and char[] are  
 subtypes of const(char)[]!

 I discussed with Walter a variant that implements equivariant functions  
 without actually adding an explicit feature to the language. Consider:

 typeof(s) stripl(const(char)[] s);

 This signature states that it returns the same type as an argument. I  
 propose that that pattern means stripl can accept _any_ subtype of  
 const(char)[] and return that exact type. Inside the function, however,  
 the type of s is the type declared, thus restricting its use.

 I need to convince myself that function bodies of this type can be  
 reliably typechecked, but first I wanted to run it by everyone to get a  
 feel of it.

 Equivariant functions are not (necessarily) templates and can be used as  
 virtual functions. Only one body is generated for one equivariant  
 function, unless other template mechanisms are in vigor.

 Here are some examples:

 a) Simple equivariance

 typeof(s) stripl(const(char)[] s);

 b) Parameterized equivariance

 typeof(s) stripl(S)(S s) if (isSomeString!S);

 c) Equivariance of field:

 typeof(s.ptr) getpointer(const(char)[] s);

 d) Equivariance inside a class/struct declaration:

 class S
 {
      typeof(this) clone();
      typeof(this.field) getfield();
      int field;
 }

 What do you think? I'm almost afraid to post this.


 Andrei


Now that I thought about it a little more (please, see and comment my post  
about typeof(this) nearby), I agree that the issues are related.

However, the best solution could be a combination of both.

For example, I agree that interface IClonable should be as follows:

interface IClonable { typeof(this) clone() const; }

But how about this scenario:

class Bar : IClonable {
     this(const(Bar) proto) { ... }
     typeof(this) clone() const { return new Bar(this); }
}

const(Bar) bar = ...;
auto barClone = bar.clone(); // typeof(barClone) is const(Bar)!

Knowing you, I expect you will suggest to change the IClonable interface  
as follows:

interface IClonable { DropConst!(typeof(this)) clone() const; }

Although I think that templates would be very useful here, I think in many  
cases they make things more complex than it could be. I believe things  
could get better if we would decouple the issue into two orthogonal  
concepts:

a) typeof(this) is a type of 'foo' in a foo.bar() expression without any  
qualifiers applied.
b) 'same' gives the qualifier which is common across all arguments 'same'  
is applied to (for example, void foo(same(A) a, same(B) b, same(C) c);,  
same is none, const or invariant).

Besides, I would be great if typeof(this) would be interchangeble with the  
actual type of this with little or no loss of meaning.

For example, with typeof(this) returning class type with all the  
qualifiers and no 'same', we would write:

class Foo
{
     typeof(this._bar) bar() const { return _bar; }
     private Bar _bar;
}

This have two negative sides:
1) we expose our internal structure
2) we need some template trickery if there is no member of type Bar inside  
Foo:

interface Foo {
     PassQual!(typeof(this), Bar) bar();
}

3) the typeof(this._bar) is not interchangeble with Bar (qualifiers are  
lost) and function doesn't work anymore (can't cast const(Bar) to Bar  
implicitly)

I also believe it is important to do the trick *without* templates,  
because there are people that don't like templates or don't know about  
them (e.g. starters).

With 'same' returning qualifiers of the arguments (hidden ones included),  
we could write as follows:

interface Foo {
     same(Bar) bar() same(this);
}

interface IClonable {
     typeof(this) clone(); // nothing else is needed! typeof(this) doesn't  
contain qualifiers.
}

note that changing typeof(this) -> IClonable works well here, too.

Another example. We will use both of the concepts in pair now:

class A
{
     same(typeof(this)) foo() same(this) {
         // do something
         return this;
     }
}

class B : A
{
     same(typeof(this)) foo() same(this) {
         super.foo();
         bar();
         return this;
     }
     void bar() {}
}

Little is changed if we replace typeof(this) with A and B in first and  
second classes respectively.

A short summary:

- typeof(s) is not very suitable for deducing qualifiers. It is quite ugly  
and not intuitive. See Christopher's comment:
On Wed, 15 Oct 2008 04:09:59 +0400, Christopher Wright  
<dhasenan gmail.com> wrote:

 typeof(s) foo(const(char)[] s)

 This looks like it's shorthand for:
 const(char)[] foo(const(char)[] s)

 And the examples with typeof(A), where A is a type, just didn't make any  
 sense.


- There are cases where typeof(s) can't be applied at all (e.g. multiple  
argument parameters). inout/same is essential here
- typeof(s) requires templates in way too many cases. same could be used  
to pass qualifiers without templates
- dividing the concepts into two orthogonal may make it both easier to  
implement and easier to understand
- this will also not overload the meaning of typeof() with too much  
different concepts

This is just an idea, what do you think?
Oct 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Denis Koroskin" wrote

 Now that I thought about it a little more (please, see and comment my post 
 about typeof(this) nearby), I agree that the issues are related.

 However, the best solution could be a combination of both.

 For example, I agree that interface IClonable should be as follows:

 interface IClonable { typeof(this) clone() const; }


No.  IClonable should be:

IClonable clone() const;

or if you prefer:

Object clone() const;

It can't be anything else, because IClonable cannot define how many levels 
deep it goes.

For example, if I have:

class A : IClonable
{
  typeof(this) clone() const { return new A();}
}

class B : A
{
}

B b = new B;
B x = b.clone();

Oops, b.clone() really only returns A, so this should fail.  The real 
signature in A should be:

class A : IClonable
{
   A clone() const { return new A(); }
}

IClonable is a perfect candidate for covariant functions, which is already 
defined.

-Steve
Oct 14 2008
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Steven Schveighoffer wrote:

 class A : IClonable
 {
   typeof(this) clone() const { return new A();}
 }
 
 class B : A
 {
 }
 
 B b = new B;
 B x = b.clone();
 
 Oops, b.clone() really only returns A, so this should fail.  The real 
 signature in A should be:


No, b.clone() definitely returns an instance of B. It's purely 
coincidental (from the caller's perspective) that B's implementation is 
identical to that of A.

Though I always thought the correct implementation of ICloneable was 
like this:

    interface ICloneable(T) {
       T clone();
    }

    A : ICloneable!(A) {
       public A clone() { ... }
    }

I really don't see what all the fuss is about with the equivariance 
stuff, except that it introduces a lot of confusing rules to fix the 
holes in the (already complex and confusing) const system.

Any other use case where equivariance might apply (other than the const 
stuff) seems to already have a simple, straightforward solution using 
either templates, interfaces, or plain old overloads.

--benji
Oct 14 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 I really don't see what all the fuss is about with the equivariance 
 stuff, except that it introduces a lot of confusing rules to fix the 
 holes in the (already complex and confusing) const system.


Please stop perpetuating misunderstanding and apprehension about the 
const system through statements strong on opinion and vague on detail. 
If you're willing to mention holes, complexity, and confusion about the 
const system, please explain where the holes are, where the complexities 
lie, and what aspects you are confused about. Suggestions for fixing 
said issues would also be welcome.

Andrei
Oct 14 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 Benji Smith wrote:

 I really don't see what all the fuss is about with the equivariance 
 stuff, except that it introduces a lot of confusing rules to fix the 
 holes in the (already complex and confusing) const system.


 
 Please stop perpetuating misunderstanding and apprehension about the 
 const system through statements strong on opinion and vague on detail. 
 If you're willing to mention holes, complexity, and confusion about the 
 const system, please explain where the holes are, where the complexities 
 lie, and what aspects you are confused about. Suggestions for fixing 
 said issues would also be welcome.


Fair enough. Here are the reasons I describe the const system as "complex":

* Comparable code without const qualifiers contains quantatitively fewer 
semantic constructs than code that uses those qualifiers. Smaller 
function prototypes are easier to read and comprehend:

    char[] join(char[] str2, char[] str2) { ... }

    const(char)[] join(const(char)[] str1, const(char)[] str1) { ... }

* Nestable const type constructors require me to keep a more detailed 
mental model of the type system. Am I using a "const(char)[]" or a 
"const(char[])"?

* Remembering the difference between "const" and "invariant" requires 
more mental energy than using a system (D1) where such distinctions 
don't exist.

* The idea that "const" is a supertype of "mutable" and "invariant" is 
utterly bizarre to me, since it violates the "is a" rule of type 
hierarchies. I understand that, for the sake of overloading, both 
"mutable" and "invariant"  can be implicitly cast to "const", but the 
other implications of that relationship are beyond my grasp at the moment.

* The transitivity of const qualifiers requires me to consider not just 
the object I'm passing around, but the references to other objects 
contained within the const-qualified object.

* Both "const" and "invariant" can apply to value-type objects. But 
"const" doesn't make any sense in that context, so in my mind I have to 
use the "invariant" concept instead whenever applying the concept to a 
primitive value.

* The equivariance proposal, at least in some of its forms, requires me 
to imagine the existence of implicit typedefs at the function-call site, 
and to know that the declared type in my method signature might not be 
the actual type of the arguments received by the function.

The "holes" I described in the const system are the symptoms being 
addressed by the equivariance proposal. Without equivariance, the const 
system sometimes requires verbatim duplication of code within function 
bodies whose only difference is their signature. Without the const 
system, the equivariance proposal wouldn't be necessary.

And the reason I describe the const system as "confusing"?

Because it confuses me.

I understand some of the allure of having a robust, provably correct 
const system. Automatic memoization would be cool. Automatic parallel 
execution would be nice. And, in theory, it'd be nice to avoid errors 
that occur when a piece of code modifies a piece of data that it shouldn't.

But in my experience (using languages that lack any sort of const 
system, except for enum-style declarations), it just doesn't matter 
much. When I need memoization or parallel execution, I write the code 
explicitly. And when I need an immutable object, I design its interface 
to make external mutation impossible (see also: java.lang.String).

It's indisputable that the D2 const system is measurably more complex 
than the D1 const system.

For me, the cost of that complexity significantly outweighs the benefit.

--benji
Oct 14 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Benji Smith wrote:

 Andrei Alexandrescu wrote:

 Benji Smith wrote:

 I really don't see what all the fuss is about with the equivariance 
 stuff, except that it introduces a lot of confusing rules to fix the 
 holes in the (already complex and confusing) const system.


 Please stop perpetuating misunderstanding and apprehension about the 
 const system through statements strong on opinion and vague on detail. 
 If you're willing to mention holes, complexity, and confusion about 
 the const system, please explain where the holes are, where the 
 complexities lie, and what aspects you are confused about. Suggestions 
 for fixing said issues would also be welcome.


 
 Fair enough. Here are the reasons I describe the const system as "complex":
 
 * Comparable code without const qualifiers contains quantatitively fewer 
 semantic constructs than code that uses those qualifiers. Smaller 
 function prototypes are easier to read and comprehend:
 
    char[] join(char[] str2, char[] str2) { ... }
 
    const(char)[] join(const(char)[] str1, const(char)[] str1) { ... }
 
 * Nestable const type constructors require me to keep a more detailed 
 mental model of the type system. Am I using a "const(char)[]" or a 
 "const(char[])"?
 
 * Remembering the difference between "const" and "invariant" requires 
 more mental energy than using a system (D1) where such distinctions 
 don't exist.
 
 * The idea that "const" is a supertype of "mutable" and "invariant" is 
 utterly bizarre to me, since it violates the "is a" rule of type 
 hierarchies. I understand that, for the sake of overloading, both 
 "mutable" and "invariant"  can be implicitly cast to "const", but the 
 other implications of that relationship are beyond my grasp at the moment.
 
 * The transitivity of const qualifiers requires me to consider not just 
 the object I'm passing around, but the references to other objects 
 contained within the const-qualified object.
 
 * Both "const" and "invariant" can apply to value-type objects. But 
 "const" doesn't make any sense in that context, so in my mind I have to 
 use the "invariant" concept instead whenever applying the concept to a 
 primitive value.
 
 * The equivariance proposal, at least in some of its forms, requires me 
 to imagine the existence of implicit typedefs at the function-call site, 
 and to know that the declared type in my method signature might not be 
 the actual type of the arguments received by the function.
 
 The "holes" I described in the const system are the symptoms being 
 addressed by the equivariance proposal. Without equivariance, the const 
 system sometimes requires verbatim duplication of code within function 
 bodies whose only difference is their signature. Without the const 
 system, the equivariance proposal wouldn't be necessary.
 
 And the reason I describe the const system as "confusing"?
 
 Because it confuses me.
 
 I understand some of the allure of having a robust, provably correct 
 const system. Automatic memoization would be cool. Automatic parallel 
 execution would be nice. And, in theory, it'd be nice to avoid errors 
 that occur when a piece of code modifies a piece of data that it shouldn't.
 
 But in my experience (using languages that lack any sort of const 
 system, except for enum-style declarations), it just doesn't matter 
 much. When I need memoization or parallel execution, I write the code 
 explicitly. And when I need an immutable object, I design its interface 
 to make external mutation impossible (see also: java.lang.String).
 
 It's indisputable that the D2 const system is measurably more complex 
 than the D1 const system.
 
 For me, the cost of that complexity significantly outweighs the benefit.
 
 --benji


In my ideal language, I'd like a const system where instead of the 
instances of types (primitive or not) being qualified, the types 
themselves were. So a "const class" or "const struct" would mean that 
every instance of that type is constant after construction.

So you'd have:
---
class MutableType
{
     int x;
     this(int _x) { this.x = _x; }
}
const class ConstType {
     int x;
     this(int _x) { this.x = _x; }
}
MutableType m = new MutableType(5);
ConstType c = new ConstType(5);
m.x = 10; // OK
c.x = 10; // ERROR
---

All classes that extend a const class would also need to be const. As 
for primitives, they would either be manifest-constant or mutable like 
in D1. This covers most common use cases very well (except for constant 
arrays... hmmmm....) and is easy for the user to understand. Plus, a 
"const class" under this system is the same as an "invariant" under the 
current system, so no synchronization required. Making invariant classes 
(classes that are final and where all members are final) are a common 
design pattern in Java.

But I'm dreaming here since Walter seems dead-set on this system.
Oct 15 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Robert Fraser <fraserofthenight gmail.com> wrote:


 In my ideal language, I'd like a const system where instead of the  
 instances of types (primitive or not) being qualified, the types  
 themselves were. So a "const class" or "const struct" would mean that  
 every instance of that type is constant after construction.

 So you'd have:
 ---
 class MutableType
 {
      int x;
      this(int _x) { this.x = _x; }
 }
 const class ConstType {
      int x;
      this(int _x) { this.x = _x; }
 }
 MutableType m = new MutableType(5);
 ConstType c = new ConstType(5);
 m.x = 10; // OK
 c.x = 10; // ERROR
 ---

 All classes that extend a const class would also need to be const. As  
 for primitives, they would either be manifest-constant or mutable like  
 in D1. This covers most common use cases very well (except for constant  
 arrays... hmmmm....) and is easy for the user to understand. Plus, a  
 "const class" under this system is the same as an "invariant" under the  
 current system, so no synchronization required. Making invariant classes  
 (classes that are final and where all members are final) are a common  
 design pattern in Java.

 But I'm dreaming here since Walter seems dead-set on this system.


Like in current d2, you mean?

const class foo
{
}

class bar : foo
{
}

void main()
{
	auto a = new foo();
	auto b = new bar();
	foo f = new foo();
	
	writefln(typeof(a).stringof);  // prints const(foo)
	writefln(typeof(b).stringof);  // prints const(bar)
	writefln(typeof(f).stringof);  // prints const(foo)
}

-- 
Simen
Oct 15 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Simen Kjaeraas wrote:

 Robert Fraser <fraserofthenight gmail.com> wrote:
 

 In my ideal language, I'd like a const system where instead of the 
 instances of types (primitive or not) being qualified, the types 
 themselves were. So a "const class" or "const struct" would mean that 
 every instance of that type is constant after construction.

 So you'd have:
 ---
 class MutableType
 {
      int x;
      this(int _x) { this.x = _x; }
 }
 const class ConstType {
      int x;
      this(int _x) { this.x = _x; }
 }
 MutableType m = new MutableType(5);
 ConstType c = new ConstType(5);
 m.x = 10; // OK
 c.x = 10; // ERROR
 ---

 All classes that extend a const class would also need to be const. As 
 for primitives, they would either be manifest-constant or mutable like 
 in D1. This covers most common use cases very well (except for 
 constant arrays... hmmmm....) and is easy for the user to understand. 
 Plus, a "const class" under this system is the same as an "invariant" 
 under the current system, so no synchronization required. Making 
 invariant classes (classes that are final and where all members are 
 final) are a common design pattern in Java.

 But I'm dreaming here since Walter seems dead-set on this system.


 
 Like in current d2, you mean?
 
 const class foo
 {
 }
 
 class bar : foo
 {
 }
 
 void main()
 {
     auto a = new foo();
     auto b = new bar();
     foo f = new foo();
     
     writefln(typeof(a).stringof);  // prints const(foo)
     writefln(typeof(b).stringof);  // prints const(bar)
     writefln(typeof(f).stringof);  // prints const(foo)
 }
 


Well, yes and no. That is typeof(a) would be just "foo", there would be 
no such thing as a const(foo). Instances of foo just couldn't be changed 
after construction, and the compiler could apply invariant optimizations 
to it as usual. That is, there would be no user-visible const except for 
the ability to declare constant classes/structs.
Oct 16 2008
prev sibling next sibling parent Gide Nwawudu <gide btinternet.com> writes:
On Tue, 14 Oct 2008 22:51:46 -0400, Benji Smith
<dlanguage benjismith.net> wrote:


Andrei Alexandrescu wrote:

 Benji Smith wrote:

 I really don't see what all the fuss is about with the equivariance 
 stuff, except that it introduces a lot of confusing rules to fix the 
 holes in the (already complex and confusing) const system.


 
 Please stop perpetuating misunderstanding and apprehension about the 
 const system through statements strong on opinion and vague on detail. 
 If you're willing to mention holes, complexity, and confusion about the 
 const system, please explain where the holes are, where the complexities 
 lie, and what aspects you are confused about. Suggestions for fixing 
 said issues would also be welcome.


Fair enough. Here are the reasons I describe the const system as "complex":

* Comparable code without const qualifiers contains quantatitively fewer 
semantic constructs than code that uses those qualifiers. Smaller 
function prototypes are easier to read and comprehend:

    char[] join(char[] str2, char[] str2) { ... }


But how would you know that the parameters are not modified? This
could lead to unnecessary dups in the client code. Personally, I think
it is easier to read a function signature, however complex, than to
read the function body.

The syntax is very important to the understanding of the concept, so
far I like the idea of 'const?' and the typedef{} idea, but maybe
reusing the keyword 'auto' could also work?

class S
{
     auto(this) clone();
     auto(this.field) getfield();
     int field;
}

Gide
Oct 15 2008
prev sibling next sibling parent Gide Nwawudu <gide btinternet.com> writes:
On Tue, 14 Oct 2008 22:51:46 -0400, Benji Smith
<dlanguage benjismith.net> wrote:

[snip]

It's indisputable that the D2 const system is measurably more complex 
than the D1 const system.

For me, the cost of that complexity significantly outweighs the benefit.

--benji


The following bug illustrates the issues users can have with D1's
const system.

http://d.puremagic.com/issues/show_bug.cgi?id=2418

Gide
Oct 15 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu wrote:

 Benji Smith wrote:

 I really don't see what all the fuss is about with the equivariance 
 stuff, except that it introduces a lot of confusing rules to fix the 
 holes in the (already complex and confusing) const system.


 Please stop perpetuating misunderstanding and apprehension about the 
 const system through statements strong on opinion and vague on detail. 
 If you're willing to mention holes, complexity, and confusion about 
 the const system, please explain where the holes are, where the 
 complexities lie, and what aspects you are confused about. Suggestions 
 for fixing said issues would also be welcome.


 
 Fair enough. Here are the reasons I describe the const system as "complex":


I see where you're coming from. If your opinion is that the const system 
does not bring enough benefits to justify its learning, you are of 
course entitled to it. But talking about complexity implies that there 
would be simpler ways to achieve its charter that we missed, and talking 
about holes that we made mistakes of principle that go beyond bugs in 
the compiler or incompleteness of implementation.


 * Comparable code without const qualifiers contains quantatitively fewer 
 semantic constructs than code that uses those qualifiers. Smaller 
 function prototypes are easier to read and comprehend:
 
    char[] join(char[] str2, char[] str2) { ... }
 
    const(char)[] join(const(char)[] str1, const(char)[] str1) { ... }


Complexity should be judged in proportion to the goal achieved. Of 
course an AM radio will be less complex than an AM/FM radio; that does 
not reveal an intrinsic problem with the latter. And the more complex 
signature tells you that join will not change its arguments. As Gide 
mentioned, one source of bugs in a D program is that attention must be 
paid to duplicating aliased slices properly. That wouldn't be bad if 
such mistakes were easily detected. Unfortunately, forgetting to call 
.dup causes long-distance coupling that make changing one piece of data 
in one place influence the change in an unrelated part, just because 
they share some history.


 * Nestable const type constructors require me to keep a more detailed 
 mental model of the type system. Am I using a "const(char)[]" or a 
 "const(char[])"?


You don't need to keep a more detailed mental model of the type system - 
whatever that is :o). On the contrary, const allows you to free your 
mind of many details about the data flow in your application. If you 
make a mistake regarding const(char)[] vs. const(char[]), the compiler 
will tell you about it, not one night of debugging.


 * Remembering the difference between "const" and "invariant" requires 
 more mental energy than using a system (D1) where such distinctions 
 don't exist.


I think this reflects a misunderstanding of what constness is supposed 
to do for you. It's exactly the contrary. Invariant reduces the amount 
of mental energy you need to expend. I think you owe it to yourself to 
use D2. You will see that using invariant strings is a huge improvement 
and it alone is worth introducing constness. Literally all bugs caused 
by undue aliasing disappear if you use string. You will see that the net 
result is that your programs are easier to write and understand, not harder.


 * The idea that "const" is a supertype of "mutable" and "invariant" is 
 utterly bizarre to me, since it violates the "is a" rule of type 
 hierarchies. I understand that, for the sake of overloading, both 
 "mutable" and "invariant"  can be implicitly cast to "const", but the 
 other implications of that relationship are beyond my grasp at the moment.


You may want to reframe this as an opportunity to improve your 
understanding of subtyping. I recommend a classic paper by Cardelli and 
Wegner "On understanding Types, Data Abstraction, and Polymorphism" 
(http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf). It's a 
classic. Reading through section 1.5 does not require much background 
and is very rewarding.

That's not to say using const and invariant requires formal background. 
Most people would just use them for their benefits and have them just 
work. But if you want to lift the hood and see exactly why they work, 
you have to get your hands greasy a bit.


 * The transitivity of const qualifiers requires me to consider not just 
 the object I'm passing around, but the references to other objects 
 contained within the const-qualified object.


This is backwards, too. If const didn't exist or weren't transitive, 
you'd be required to keep in mind for mutation and aliasing bugs not 
just the object you're passing around, but the references to other objects.


 * Both "const" and "invariant" can apply to value-type objects. But 
 "const" doesn't make any sense in that context, so in my mind I have to 
 use the "invariant" concept instead whenever applying the concept to a 
 primitive value.


Of course it does make sense. The address of a const int has a different 
type than the address of a mutable int. Again the pattern is that you 
have less, not more to keep in mind. The type "keeps it in its mind" for 
you.


 * The equivariance proposal, at least in some of its forms, requires me 
 to imagine the existence of implicit typedefs at the function-call site, 
 and to know that the declared type in my method signature might not be 
 the actual type of the arguments received by the function.


Not at all. On this group many people have high competency and willing 
to discuss the most minute implementation details of a language feature, 
and my understanding is that you also engage in such discussions. On 
occasion, therefore, there will be discussion on exactly how sausages 
are being made. Do not confuse those discussions with things that 
complicate the experience of eating sausages.

Much of the problems caused by const equivariance is just that Walter is 
leery of implementing aliases bound to qualifiers. If he would, there 
would be no problem to talk about. The issues with const equivariance, 
in that case, would be exactly the same as with supporting equivariance 
for any types in general.


 The "holes" I described in the const system are the symptoms being 
 addressed by the equivariance proposal.


You did not describe any hole above. In fact, on first reading, at this 
point I was expecting you'd start describing the actual holes that I 
know about - e.g. the impossibility of creating invariant objects 
without a cast. (That will be fixed.)


 Without equivariance, the const 
 system sometimes requires verbatim duplication of code within function 
 bodies whose only difference is their signature. Without the const 
 system, the equivariance proposal wouldn't be necessary.


No. Without equivariance, you'd be required to duplicate bodies of 
functions that need it, such as clone. It is true that const makes that 
need more frequent, but that does not reveal a problem intrinsic to it 
or a mistake in defining it.


 And the reason I describe the const system as "confusing"?
 
 Because it confuses me.


This is a fair point. One problem is that right now no good description 
of const exists. Worse, trying to infer it from discussions on this 
group is bound to scare one away because here mostly problems are 
discussed.


 I understand some of the allure of having a robust, provably correct 
 const system. Automatic memoization would be cool. Automatic parallel 
 execution would be nice. And, in theory, it'd be nice to avoid errors 
 that occur when a piece of code modifies a piece of data that it shouldn't.
 
 But in my experience (using languages that lack any sort of const 
 system, except for enum-style declarations), it just doesn't matter 
 much. When I need memoization or parallel execution, I write the code 
 explicitly. And when I need an immutable object, I design its interface 
 to make external mutation impossible (see also: java.lang.String).


There's been a pretty incredible resurgence in interest in functional 
programming languages. At ACCU 2008 (www.accu.org), previously a 
"no-quarters" hardcore C++ conference, who do you think gave keynotes 
and talks? Simon Peyton-Jones, the inventor of Haskell, and Joe 
Armstrong, inventor of Erlang. To better understand the size of that 
change, you must browse through previous years' conference programs. 
Only 2-3 years ago that very concept would have been unbelievable. ACCU 
stands for Association of C and C++ Users! Use of Haskell and Erlang is 
increasing exponentially. Even mainstream companies started using them. 
Others (big, big companies that shall not be named) are designing their 
own languages. And guess what - they _all_ have a notion of immutability.

What do functional languages have? Do you think people like them for the 
monads? It's the immutability. They've been embracing and dealing with 
it for years. And that gives them a ready answer to today's 2000-lbs 
pink elephant in the room - the manycores. Having made a resolute step 
towards classic, deadlock-oriented programming, Java is now in the 
unpleasant position of having invested it money in the wrong stock, just 
like it did with UTF-16. So when people think manycores, they look away 
from Java.


 It's indisputable that the D2 const system is measurably more complex 
 than the D1 const system.
 
 For me, the cost of that complexity significantly outweighs the benefit.


It is fair to hold such a belief. I think it would be helpful to 
reevaluate it in wake of the above.


Andrei
Oct 15 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Hey, Andrei!

First of all, just let me say how much I appreciate your detailed 
responses. I hope you don't ever take my feedback as a personal 
criticism or as being harshly negative. The only reason I've continued 
to engage is these kinds of debates for the last five years or so is 
because D interests me very much, and I'd like to see it meet its 
fullest potential. I know you have the same end-goals in mind, though we 
sometimes disagree about the most effective route from point A to point B.

Andrei Alexandrescu wrote:

 I see where you're coming from. If your opinion is that the const system 
 does not bring enough benefits to justify its learning, you are of 
 course entitled to it. But talking about complexity implies that there 
 would be simpler ways to achieve its charter that we missed, and talking 
 about holes that we made mistakes of principle that go beyond bugs in 
 the compiler or incompleteness of implementation.


Yeah, I see where you're coming from too. I think you guys have done an 
admirable job thinking through the corner cases and figuring out ways to 
solve many of the sticky design issues that have arisen.

On the other hand, there was a const proposal...maybe six months or a 
year ago...where all function parameters would be considered immutable 
by default, unless annotated as mutable.

I thought that idea had a lot of merit. My first impression was that 
it'd provide more reliable guarantees, since it would be impossible to 
accidentally create a mutable param by forgetting to declare its 
constness. It also seemed like it would have resulted in more compact 
method signatures (since const arguments are generally more common than 
mutable arguments), and less overall risk of aliasing.

For me, one of the main perks of the other proposal was less "const" 
litter all over the code, and yet with stronger const safety.

Also, a function promising not to modify its arguments seems more like 
an attribute of the function, not of the arguments themselves.

But I digress...


 * Nestable const type constructors require me to keep a more detailed 
 mental model of the type system. Am I using a "const(char)[]" or a 
 "const(char[])"?


 
 You don't need to keep a more detailed mental model of the type system - 
 whatever that is :o). On the contrary, const allows you to free your 
 mind of many details about the data flow in your application. If you 
 make a mistake regarding const(char)[] vs. const(char[]), the compiler 
 will tell you about it, not one night of debugging.


The "mental model" is my cute little informal way of referring to the 
body of knowledge necessary to operate some contraption (like a can 
opener or a compiler).

In order to make the gizmo do what I want it to do, I have to form a 
(perhaps simplified) mental picture of the cause-and-effect chain that 
connects the inputs with the outputs.

Driving a car with a manual transmission requires a more detailed mental 
model than driving an automatic. Maybe the manual transmission offers 
other advantages, but ease-of-use is not one of them.


 * Remembering the difference between "const" and "invariant" requires 
 more mental energy than using a system (D1) where such distinctions 
 don't exist.


 
 I think this reflects a misunderstanding of what constness is supposed 
 to do for you. It's exactly the contrary. Invariant reduces the amount 
 of mental energy you need to expend. I think you owe it to yourself to 
 use D2. You will see that using invariant strings is a huge improvement 
 and it alone is worth introducing constness. Literally all bugs caused 
 by undue aliasing disappear if you use string. You will see that the net 
 result is that your programs are easier to write and understand, not 
 harder.


I actually plan on giving D2 a spin as soon as a compatible version of 
Tango is available.

And I actually totally agree with you about invariant strings. The 

strings, without the languages having a const system like D. In those 
languages, immutability is achieved by convention.

It's a tradeoff, sure.

Especially when implementing a new class, you have to think carefully 
about when to make defensive copies in getters and setters. And external 
consumers of your classes, who might not know where the defensive copies 
occur, might create their own defensive copies before calling one of 
your API methods. In that respect, a const system is alluring because it 
eliminates the need for those kinds of considerations.

But the const system just smells bad to me. I've tried to enumerate my 
reasons, and maybe switching to D2 will change my mind. But right now, 
I'm calling it as I see it. You asked for feedback, and you got it!!

I'll make an analogy.

I also find the concept of range-bound numeric types very appealing. 
It'd be nice to declare that a function takes an argument whose value is 
a "double greater than zero but less than or equal to one". A lot of my 
statistical code would benefit from that kind of type declaration, and 
I'd be able to get rid of a few lines of argument-validity-checking code 
from the preamble of every function implementation.

While we're at it, I can also think of examples where I might like to 
say that a function accepts a "feature vector whose magnitude is exactly 
equal to 1.0".

Input validation is one of those nasty cross-cutting concerns, and it'd 
be nice to have a general-purpose, language-level solution to the problem.

It doesn't take too much imagination to sketch out a design for 
extending the type system to allow for those kinds of value constraints. 
With such a type calculus in place, it would probably be possible to 
implement a general purpose solver that would enable a whole host of 
interesting optimizations.

If I'm not mistaken, that's the basic idea of many functional 
languages... That by moving computation into the type system, the 
algebraic rules governing those types can be solved by applying 
well-known type transformations, often in parallel.

Nevertheless, I think range-bound types would be a mistake to implement 
in D. I can't completely articulate why I feel that way, but part of it 
has to do with the increasing complexity of function prototype 
declarations. And, it's also partly because validation can already be 
accomplished in an "in" contract.

To me, the const system has the same basic characteristics: it's a major 
language feature, with lots of corner cases, to solve a problem that I 
either don't have or have already found a reasonable (if not ideal) 
solution.


 * The idea that "const" is a supertype of "mutable" and "invariant" is 
 utterly bizarre to me, since it violates the "is a" rule of type 
 hierarchies. I understand that, for the sake of overloading, both 
 "mutable" and "invariant"  can be implicitly cast to "const", but the 
 other implications of that relationship are beyond my grasp at the 
 moment.


 
 You may want to reframe this as an opportunity to improve your 
 understanding of subtyping. I recommend a classic paper by Cardelli and 
 Wegner "On understanding Types, Data Abstraction, and Polymorphism" 
 (http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf). It's a 
 classic. Reading through section 1.5 does not require much background 
 and is very rewarding.


I just read section 1.5 and don't find anything outlandish there.

And I've added the paper to my reading list. Language design is fun, and 
I'm always looking for new good source material :)


 * The transitivity of const qualifiers requires me to consider not 
 just the object I'm passing around, but the references to other 
 objects contained within the const-qualified object.


 
 This is backwards, too. If const didn't exist or weren't transitive, 
 you'd be required to keep in mind for mutation and aliasing bugs not 
 just the object you're passing around, but the references to other objects.


Again, I'd like to reaffirm my agreement that immutable objects are 
valuable. No disagreement from me there!

I'm just used to an ecosystem where immutability is by convention, and 
the language-level immutability in D strikes me as somewhat heavy-handed.


 * The equivariance proposal, at least in some of its forms, requires 
 me to imagine the existence of implicit typedefs at the function-call 
 site, and to know that the declared type in my method signature might 
 not be the actual type of the arguments received by the function.


 
 Not at all. On this group many people have high competency and willing 
 to discuss the most minute implementation details of a language feature, 
 and my understanding is that you also engage in such discussions. On 
 occasion, therefore, there will be discussion on exactly how sausages 
 are being made. Do not confuse those discussions with things that 
 complicate the experience of eating sausages.


Yep! I love to engage in these kinds of discussions!

And I hope you take this in the spirit of informed disagreement. I read 
about 90% of the messages in this NG, paying particular attention to the 
language-design discussions. I've taken the stuff I learned in this NG 
from geniuses like you and Walter, and used it in real-life projects, 
implementing a domain-specific language and compiler for one of my 
former employers.

I'm sure you get tired of people throwing stones at your design 
concepts, especially without a detailed explanation. But I think many of 
us also get tired of being told "if you really understood, you'd agree".

I may not fully understand all the details, but I understand enough to 
know that I'm not a fan.

And I disagree about the "sausage-making". I've never successfully used 
a language feature, in any programming language, where I didn't 
understand the underlying mechanics of the implementation. Anyone 
writing code who doesn't know how it works under the hood is just a 
copy-paste programmer.

Anyhow, I'll leave it at that.

Since this community presumably exists to support a collaborative 
environment for advancing the D language (and does a remarkably good job 
of it in the vast majority of cases), I just wanted to put my vote in 
the ballot-box.

:-)

--benji
Oct 15 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Hey, Andrei!
 
 First of all, just let me say how much I appreciate your detailed 
 responses. I hope you don't ever take my feedback as a personal 
 criticism or as being harshly negative. The only reason I've continued 
 to engage is these kinds of debates for the last five years or so is 
 because D interests me very much, and I'd like to see it meet its 
 fullest potential. I know you have the same end-goals in mind, though we 
 sometimes disagree about the most effective route from point A to point B.


That is highly appreciated.


 Andrei Alexandrescu wrote:

 I see where you're coming from. If your opinion is that the const 
 system does not bring enough benefits to justify its learning, you are 
 of course entitled to it. But talking about complexity implies that 
 there would be simpler ways to achieve its charter that we missed, and 
 talking about holes that we made mistakes of principle that go beyond 
 bugs in the compiler or incompleteness of implementation.


 
 Yeah, I see where you're coming from too. I think you guys have done an 
 admirable job thinking through the corner cases and figuring out ways to 
 solve many of the sticky design issues that have arisen.
 
 On the other hand, there was a const proposal...maybe six months or a 
 year ago...where all function parameters would be considered immutable 
 by default, unless annotated as mutable.


Sure. I suggested that to Walter two years ago, or maybe three. It was 
one of the first suggestion I made: you should make everything immutable 
by default, and mutable only if explicitly specified. (That's what e.g. 
ML and Cecil do.) He also liked it: instead of littering code with const 
this and immutable that, you only have var here and there - and maybe 
mutation is much less rarely needed than we think. In the end we 
rejected the idea because we thought it'll scare away people coming from 
C++ and Java. It was also too big a change from what D was at that 
point. So we had to drop that.

But don't think for a moment that that approach would have been one iota 
simpler than what we have now. Supporting mutation and immutability in 
the same range is a sort of constant-sum game - you can pick your 
defaults, but overall the pie has the same size.


 I thought that idea had a lot of merit. My first impression was that 
 it'd provide more reliable guarantees, since it would be impossible to 
 accidentally create a mutable param by forgetting to declare its 
 constness. It also seemed like it would have resulted in more compact 
 method signatures (since const arguments are generally more common than 
 mutable arguments), and less overall risk of aliasing.
 
 For me, one of the main perks of the other proposal was less "const" 
 litter all over the code, and yet with stronger const safety.


You'll be glad then to learn that "in" means const at least in D2:

void foo(in char[] s); // same as foo(const(char)[] s)


 Also, a function promising not to modify its arguments seems more like 
 an attribute of the function, not of the arguments themselves.


The signature of the function _is_ an attribute of the function.


 But I digress...


It's a good digression.


 Driving a car with a manual transmission requires a more detailed mental 
 model than driving an automatic. Maybe the manual transmission offers 
 other advantages, but ease-of-use is not one of them.


Hmmmm. I'd compare the wild west when everything is mutable at any time 
much more with an unwieldy manual-transmission car that leaks oil and 
blows a gasket every so often. That's congruent with my earlier point: 
you think const is more trouble for you. IMHO it's exactly, but I mean 
exactly, the opposite.


 I actually plan on giving D2 a spin as soon as a compatible version of 
 Tango is available.


[snip]

 But the const system just smells bad to me. I've tried to enumerate my 
 reasons, and maybe switching to D2 will change my mind. But right now, 
 I'm calling it as I see it. You asked for feedback, and you got it!!


Now I'm not sure how to sugarcoat or spin positively or put nicely what 
I'm going to say. Let me try (actually it took me a couple of minutes to 
figure out a formula).

At least to me, "feedback" implies a closed-loop system. Stuff happens, 
has consequences, the consequences are observed, and information is 
"fed" "back" to the system. In our case, I'd say that using const is an 
absolute prerequisite for feedback to be taken seriously, particularly 
when it's as informal as "just smells bad to me". Otherwise I think 
"candid opinion" is the best way I can put it. Sorry.

[snip]

 Since this community presumably exists to support a collaborative 
 environment for advancing the D language (and does a remarkably good job 
 of it in the vast majority of cases), I just wanted to put my vote in 
 the ballot-box.
 
 :-)


Please get information on the candidate before voting.

Andrei
Oct 15 2008
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 Now I'm not sure how to sugarcoat or spin positively or put nicely what 
 I'm going to say. Let me try (actually it took me a couple of minutes to 
 figure out a formula).
 
 At least to me, "feedback" implies a closed-loop system. Stuff happens, 
 has consequences, the consequences are observed, and information is 
 "fed" "back" to the system. In our case, I'd say that using const is an 
 absolute prerequisite for feedback to be taken seriously, particularly 
 when it's as informal as "just smells bad to me". Otherwise I think 
 "candid opinion" is the best way I can put it. Sorry.
 
 [snip]

 Since this community presumably exists to support a collaborative 
 environment for advancing the D language (and does a remarkably good 
 job of it in the vast majority of cases), I just wanted to put my vote 
 in the ballot-box.

 :-)


 
 Please get information on the candidate before voting.


Point taken.

I withdraw my comments about the const system, and from now on, I'll 
only critique stuff I've actually used, rather than proposals I've read 
and whose issues I've only imagined.

And, as always, no harm no foul.

--benji
Oct 15 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Benji,


 Andrei Alexandrescu wrote:
 

 Now I'm not sure how to sugarcoat or spin positively or put nicely
 what I'm going to say. Let me try (actually it took me a couple of
 minutes to figure out a formula).
 
 At least to me, "feedback" implies a closed-loop system. Stuff
 happens, has consequences, the consequences are observed, and
 information is "fed" "back" to the system. In our case, I'd say that
 using const is an absolute prerequisite for feedback to be taken
 seriously, particularly when it's as informal as "just smells bad to
 me". Otherwise I think "candid opinion" is the best way I can put it.
 Sorry.
 
 [snip]
 

 Since this community presumably exists to support a collaborative
 environment for advancing the D language (and does a remarkably good
 job of it in the vast majority of cases), I just wanted to put my
 vote in the ballot-box.
 
 :-)
 


 Please get information on the candidate before voting.
 


 Point taken.
 
 I withdraw my comments about the const system, and from now on, I'll
 only critique stuff I've actually used, rather than proposals I've
 read and whose issues I've only imagined.
 
 And, as always, no harm no foul.
 
 --benji
 



Sorry, can't  help it:

Bravo!  Well done, you two! :)

It's a joy to read posts that are respectful and considerate, yet without 
sacrificing a certain amount of directness.  It a skill I'm still trying 
to develop.

Thanks for setting the example, guys. 

-JJR
Oct 15 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
John Reimer wrote:

 Hello Benji,
 

 Andrei Alexandrescu wrote:


 Now I'm not sure how to sugarcoat or spin positively or put nicely
 what I'm going to say. Let me try (actually it took me a couple of
 minutes to figure out a formula).

 At least to me, "feedback" implies a closed-loop system. Stuff
 happens, has consequences, the consequences are observed, and
 information is "fed" "back" to the system. In our case, I'd say that
 using const is an absolute prerequisite for feedback to be taken
 seriously, particularly when it's as informal as "just smells bad to
 me". Otherwise I think "candid opinion" is the best way I can put it.
 Sorry.

 [snip]


 Since this community presumably exists to support a collaborative
 environment for advancing the D language (and does a remarkably good
 job of it in the vast majority of cases), I just wanted to put my
 vote in the ballot-box.

 :-)


 Please get information on the candidate before voting.


 Point taken.

 I withdraw my comments about the const system, and from now on, I'll
 only critique stuff I've actually used, rather than proposals I've
 read and whose issues I've only imagined.

 And, as always, no harm no foul.

 --benji


 
 
 Sorry, can't  help it:
 
 Bravo!  Well done, you two! :)
 
 It's a joy to read posts that are respectful and considerate, yet 
 without sacrificing a certain amount of directness.  It a skill I'm 
 still trying to develop.
 
 Thanks for setting the example, guys.
 -JJR


Agreed. I'm telling you: this is so nice, I thought there for a moment 
that someone was impersonating me :o).

Andrei
Oct 15 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:

 Benji Smith wrote:

 For me, one of the main perks of the other proposal was less "const" 
 litter all over the code, and yet with stronger const safety.


 
 You'll be glad then to learn that "in" means const at least in D2:
 
 void foo(in char[] s); // same as foo(const(char)[] s)


This has been an absolute godsend for writing D1->D2 portable code.  So 
much so that I'm not sure I'd have even attempted it without this feature.


 Driving a car with a manual transmission requires a more detailed 
 mental model than driving an automatic. Maybe the manual transmission 
 offers other advantages, but ease-of-use is not one of them.


 
 Hmmmm. I'd compare the wild west when everything is mutable at any time 
 much more with an unwieldy manual-transmission car that leaks oil and 
 blows a gasket every so often. That's congruent with my earlier point: 
 you think const is more trouble for you. IMHO it's exactly, but I mean 
 exactly, the opposite.


I think being const-free results in more succinct code, and I'd argue 
it's more easily readable as well, because of the syntactic dissonance 
that the const labels introduce.  But your wild west analogy is an apt 
one, because it makes data protection largely a matter of convention, 
while at least the switches and knobs of the manual transmission car 
provide a means to ensure safety at the design level.  I think one could 
argue the benefits of each.


 I actually plan on giving D2 a spin as soon as a compatible version of 
 Tango is available.


 [snip]

 But the const system just smells bad to me. I've tried to enumerate my 
 reasons, and maybe switching to D2 will change my mind. But right now, 
 I'm calling it as I see it. You asked for feedback, and you got it!!


 
 Now I'm not sure how to sugarcoat or spin positively or put nicely what 
 I'm going to say. Let me try (actually it took me a couple of minutes to 
 figure out a formula).
 
 At least to me, "feedback" implies a closed-loop system. Stuff happens, 
 has consequences, the consequences are observed, and information is 
 "fed" "back" to the system. In our case, I'd say that using const is an 
 absolute prerequisite for feedback to be taken seriously, particularly 
 when it's as informal as "just smells bad to me". Otherwise I think 
 "candid opinion" is the best way I can put it. Sorry.


I've been a fairly vocal opponent of the const system in the past, 
largely because I'm not terribly happy with the complexity it can 
introduce in user code.  However, I think it's important to note that I 
said /can/ rather than /will/.  A great deal still comes down to 
programmer skill, and the rest, hopefully, will be addressed by 
discussions such as this.


Sean
Oct 15 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:

 
 You'll be glad then to learn that "in" means const at least in D2:
 
 void foo(in char[] s); // same as foo(const(char)[] s)
 


What??
Whoa, at first I thought you were mistaken, and meant 'const(char[]) s' 
instead (since that is what is the same as 'const char[] s'), but I 
fired up my editor and tried it out, and it works as you described! Even 
more surprising, it works the same way when using a class type:

class Foo { int x; }

void func(in Foo foo, const scope Foo foo2)
{
   foo = null; // Ok!
   //foo2 = null; //Compile error!
   //foo.x = 0;  // Compile error!
   pragma(msg, (typeof(foo)).stringof ~ " " ~ (typeof(foo2)).stringof);
}

Which means 'in' works exactly as headconst! Is this another easter egg, 
or a bug? It's certainly not according to the spec at least.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 19, 2008 at 3:45 AM, Bruno Medeiros
<brunodomedeiros+spam com.gmail> wrote:

 Andrei Alexandrescu wrote:

 You'll be glad then to learn that "in" means const at least in D2:

 void foo(in char[] s); // same as foo(const(char)[] s)


 What??
 Whoa, at first I thought you were mistaken, and meant 'const(char[]) s'
 instead (since that is what is the same as 'const char[] s'), but I fired up
 my editor and tried it out, and it works as you described! Even more
 surprising, it works the same way when using a class type:

 class Foo { int x; }

 void func(in Foo foo, const scope Foo foo2)
 {
  foo = null; // Ok!
  //foo2 = null; //Compile error!
  //foo.x = 0;  // Compile error!
  pragma(msg, (typeof(foo)).stringof ~ " " ~ (typeof(foo2)).stringof);
 }

 Which means 'in' works exactly as headconst! Is this another easter egg, or
 a bug? It's certainly not according to the spec at least.


I think you mean "tailconst".  The head is not const, the tail is.

--bb
Oct 18 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:

 On Sun, Oct 19, 2008 at 3:45 AM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Andrei Alexandrescu wrote:

 You'll be glad then to learn that "in" means const at least in D2:

 void foo(in char[] s); // same as foo(const(char)[] s)


 What??
 Whoa, at first I thought you were mistaken, and meant 'const(char[]) s'
 instead (since that is what is the same as 'const char[] s'), but I fired up
 my editor and tried it out, and it works as you described! Even more
 surprising, it works the same way when using a class type:

 class Foo { int x; }

 void func(in Foo foo, const scope Foo foo2)
 {
  foo = null; // Ok!
  //foo2 = null; //Compile error!
  //foo.x = 0;  // Compile error!
  pragma(msg, (typeof(foo)).stringof ~ " " ~ (typeof(foo2)).stringof);
 }

 Which means 'in' works exactly as headconst! Is this another easter egg, or
 a bug? It's certainly not according to the spec at least.


 
 I think you mean "tailconst".  The head is not const, the tail is.
 
 --bb


Yes, exactly, I meant 'tailconst'.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 19 2008
prev sibling parent ore-sama <spam here.lot> writes:
Bruno Medeiros Wrote:


 Which means 'in' works exactly as headconst! Is this another easter egg, 
 or a bug? It's certainly not according to the spec at least.


bug in docs. in can't be scope.

docs:
For dynamic array and object parameters, which are passed by reference,
in/out/ref apply only to the reference and not the contents.
Oct 18 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Benji Smith wrote:

 
 On the other hand, there was a const proposal...maybe six months or a 
 year ago...where all function parameters would be considered immutable 
 by default, unless annotated as mutable.
 


Just a minor correction: the proposal was for all function parameters to 
be *const* by default, not immutable. (it would be a pain if it was like 
that, immutable by default)


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Benji Smith wrote:

 
 * Comparable code without const qualifiers contains quantatitively fewer 
 semantic constructs than code that uses those qualifiers. Smaller 
 function prototypes are easier to read and comprehend:
 
    char[] join(char[] str2, char[] str2) { ... }
 
    const(char)[] join(const(char)[] str1, const(char)[] str1) { ... }
 


Together with the existing 'string', I've created aliases of my own: 
'mstring', short for mutable string, same as 'char[]', and 'cstring' for 
const string, same as 'const(char)[]';
I've found they bring not only less typing, but also less mental 
workload (like, easier to read).

   cstring join(cstring str1, cstring str1) { ... }

Although that's mostly because of the fact that I don't have to 
immediately think of them as arrays of characters.


 
 * The idea that "const" is a supertype of "mutable" and "invariant" is 
 utterly bizarre to me, since it violates the "is a" rule of type 
 hierarchies. I understand that, for the sake of overloading, both 
 "mutable" and "invariant"  can be implicitly cast to "const", but the 
 other implications of that relationship are beyond my grasp at the moment.
 


Like Andrei said, it does not violate the "is a" rule of type hierarchies.
An invariant type can be used as a const type without breaking any of 
the contracts of invariant. Thus, it's a subtype as per the Liskov 
substitution principle. (and the same with mutable)


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Benji Smith" wrote

 Steven Schveighoffer wrote:

 class A : IClonable
 {
   typeof(this) clone() const { return new A();}
 }

 class B : A
 {
 }

 B b = new B;
 B x = b.clone();

 Oops, b.clone() really only returns A, so this should fail.  The real 
 signature in A should be:


 No, b.clone() definitely returns an instance of B. It's purely 
 coincidental (from the caller's perspective) that B's implementation is 
 identical to that of A.


B is definitely not the same as A.  B could have a different implementation, 
I just didn't give it one.

e.g.:

class A : IClonable
{
  typeof(this) clone() const { return new A(); }
  void foo() {writefln("This is A");}
}

class B : A
{
   void foo() {writefln("This is B");}
}

B b = new B;
b.clone().foo(); // prints "This is A"

It can't work any other way, or else the type system would be broken.

-Steve
Oct 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Benji Smith" wrote

 Steven Schveighoffer wrote:

 class A : IClonable
 {
   typeof(this) clone() const { return new A();}
 }

 class B : A
 {
 }

 B b = new B;
 B x = b.clone();

 Oops, b.clone() really only returns A, so this should fail.  The real 
 signature in A should be:


 No, b.clone() definitely returns an instance of B. It's purely 
 coincidental (from the caller's perspective) that B's implementation is 
 identical to that of A.


 
 B is definitely not the same as A.  B could have a different implementation, 
 I just didn't give it one.
 
 e.g.:
 
 class A : IClonable
 {
   typeof(this) clone() const { return new A(); }
   void foo() {writefln("This is A");}
 }
 
 class B : A
 {
    void foo() {writefln("This is B");}
 }
 
 B b = new B;
 b.clone().foo(); // prints "This is A"
 
 It can't work any other way, or else the type system would be broken.


Clone is different in two ways:

1. It must be implemented in *all* derived classes

2. For each of those classes, it must return the type of that class, not 
the type of any ancestor.

Statically enforcing both 1 and 2 is the ideal case. Some languages 
allow it by allowing classes to express the actual (leaf) type of 
"this". D doesn't. I am not sure to what extent the feature is 
necessary. I would have been happy to capture it together with 
const-equivariance, but if that doesn't work, then what can I do.


Andrei
Oct 14 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Benji Smith" wrote

 Steven Schveighoffer wrote:

 class A : IClonable
 {
   typeof(this) clone() const { return new A();}
 }

 class B : A
 {
 }

 B b = new B;
 B x = b.clone();

 Oops, b.clone() really only returns A, so this should fail.  The real 
 signature in A should be:


 No, b.clone() definitely returns an instance of B. It's purely 
 coincidental (from the caller's perspective) that B's implementation is 
 identical to that of A.


 B is definitely not the same as A.  B could have a different 
 implementation, I just didn't give it one.

 e.g.:

 class A : IClonable
 {
   typeof(this) clone() const { return new A(); }
   void foo() {writefln("This is A");}
 }

 class B : A
 {
    void foo() {writefln("This is B");}
 }

 B b = new B;
 b.clone().foo(); // prints "This is A"

 It can't work any other way, or else the type system would be broken.


 Clone is different in two ways:

 1. It must be implemented in *all* derived classes

 2. For each of those classes, it must return the type of that class, not 
 the type of any ancestor.

 Statically enforcing both 1 and 2 is the ideal case. Some languages allow 
 it by allowing classes to express the actual (leaf) type of "this". D 
 doesn't. I am not sure to what extent the feature is necessary. I would 
 have been happy to capture it together with const-equivariance, but if 
 that doesn't work, then what can I do.


I'm sure it can be done, but I wasn't thinking of that when you were 
suggesting equivariance.  That sounds more like implementation rules 
(similar to if you implement an interface, you must implement all functions 
in the interface).

What I was thinking of is putting into the signature of the function what 
the compiler has guaranteed about the return type.  i.e. the return type is 
built from argument x.

The typeof(this) seems like it has a single purpose though.  Only as the 
return type of a class member function.  It makes no sense as a struct 
member function, as you can't derive from it, and likewise for a free 
function.

I think you are talking about a third feature other than the two I 
identified elsewhere.

However, this might add to the usability of the 'return exact parameter' 
syntax.  For example, for a function foo that takes a base type A, it can't 
guarantee that it can return type that was derived from A unless it returns 
the argument itself.  But if an A class has the typeof(this) as one of its 
returns for a method, then A is guaranteeing that the return type is at 
least of the most derived type (and the compiler has already statically 
guaranteed that).

So here's what I think we could do:

1. inout (or whatever keyword people like) defines how to deal with multiple 
constancies with one function.
2. typeof(this) as a return type on an interface or class method dictates 
that
    a. all derived classes must re-implement the given function
    b. the derived class must return the most derived type in that function.
3. typeof(arg) guarantees that either
    a. the function is returning that exact arg
    b. typeof(arg) is an interface or class, and the function is returning a 
result from arg.f, where arg.f returns typeof(this).

In light of this possibility, I retract the proposal for return int x in the 
parameter list, as it would be difficult to declare a temporary variable of 
that type unambiguously.

-Steve
Oct 14 2008
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Denis Koroskin" wrote

 Now that I thought about it a little more (please, see and comment my post 
 about typeof(this) nearby), I agree that the issues are related.

 However, the best solution could be a combination of both.

 For example, I agree that interface IClonable should be as follows:

 interface IClonable { typeof(this) clone() const; }


 
 No.  IClonable should be:
 
 IClonable clone() const;


Nah, the whole goal is to have clone() in the base enforce that derivees 
implement it with the right signature...


Andrei
Oct 14 2008
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Oct 2008 05:44:22 +0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 "Denis Koroskin" wrote

 Now that I thought about it a little more (please, see and comment my  
 post
 about typeof(this) nearby), I agree that the issues are related.

 However, the best solution could be a combination of both.

 For example, I agree that interface IClonable should be as follows:

 interface IClonable { typeof(this) clone() const; }


 No.  IClonable should be:

 IClonable clone() const;

 or if you prefer:

 Object clone() const;

 It can't be anything else, because IClonable cannot define how many  
 levels
 deep it goes.


Nope, you missed the idea. Was my post too long?


 For example, if I have:

 class A : IClonable
 {
   typeof(this) clone() const { return new A();}
 }

 class B : A
 {
 }


This shouldn't compile - Error: class B doesn't implement typeof(this)  
clone() method.


 B b = new B;
 B x = b.clone();


Error: can't instantiate abstract class B.


 Oops, b.clone() really only returns A, so this should fail.  The real
 signature in A should be:

 class A : IClonable
 {
    A clone() const { return new A(); }
 }


No, you missed the idea of the discussion.


 IClonable is a perfect candidate for covariant functions, which is  
 already defined.

 -Steve
Oct 14 2008
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Denis Koroskin wrote:

 Nope, you missed the idea. Was my post too long?


Oops. You're right. Sorry about that :)

--benji
Oct 14 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Denis Koroskin" wrote

 On Wed, 15 Oct 2008 05:44:22 +0400, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:


 "Denis Koroskin" wrote

 Now that I thought about it a little more (please, see and comment my 
 post
 about typeof(this) nearby), I agree that the issues are related.

 However, the best solution could be a combination of both.

 For example, I agree that interface IClonable should be as follows:

 interface IClonable { typeof(this) clone() const; }


 No.  IClonable should be:

 IClonable clone() const;

 or if you prefer:

 Object clone() const;

 It can't be anything else, because IClonable cannot define how many 
 levels
 deep it goes.


 Nope, you missed the idea. Was my post too long?


Yes, I did miss the idea.  My apologies, I was not looking at equivariance 
meaning 'forcing derived classes to implement certain functions'.

See my later post in reply to Andrei.

Sorry for the confusion.

-Steve
Oct 14 2008