www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.161 release

reply Walter Bright <newshound digitalmars.com> writes:
Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html
Jun 19 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
<newshound digitalmars.com> wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Wow, that new literal delegate syntax is crazy but I like it. I suggest changing word lambda to literal on the changelog since lambda isn't mentioned in the spec and no need to make things more confusing. - Chris
Jun 19 2006
parent reply BCS <BCS pathlink.com> writes:
Chris Miller wrote:
 On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
 <newshound digitalmars.com> wrote:
 
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Wow, that new literal delegate syntax is crazy but I like it.

Ohhhh fun!! Try finding the bug in this one (ignore the hints). <code> #import std.stdio; #void main() #{ # writef(fn,\n); #} # #int fn() #{ # int baz() # { # return 6; # } # # void figNewton( int i, int delegate()fnp=&baz, int k=3, int l=0) # { # } # int w; # # figNewton(9,//); # { # return 1; # },//; # w = (1+3),//; # doNothing/*(*/); # # return 2; #} #int doNothing(){return 1;} </code> Yah, yah thats about a contrived a C-list movie but...
Jun 20 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
BCS wrote:
 Chris Miller wrote:
 On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
 <newshound digitalmars.com> wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Wow, that new literal delegate syntax is crazy but I like it.

Ohhhh fun!! Try finding the bug in this one (ignore the hints).

-snip- It seems to work just fine here? Prints 2, exactly what I expected :) L.
Jun 20 2006
parent BCS <BCS pathlink.com> writes:
Lionello Lunesu wrote:
 BCS wrote:
 
 Chris Miller wrote:

 On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
 <newshound digitalmars.com> wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Wow, that new literal delegate syntax is crazy but I like it.

Ohhhh fun!! Try finding the bug in this one (ignore the hints).

-snip- It seems to work just fine here? Prints 2, exactly what I expected :) L.

if about 4 typos are removes it becomes this and returns 1. <code> #import std.stdio; #void main() #{ # writef(fn,\n); #} # #int fn() #{ # int baz() # { # return 6; # } # # void figNewton( int i, int delegate()fnp=&baz, int k=3, int l=0) # { # } # int w; # # /+ # figNewton(9, # { # return 1; # }, # w = (1+3), # doNothing); # +/ # # figNewton(9); # { # return 1; # }; # w = (1+3); # doNothing); # # return 2; #} #int doNothing(){return 1;} </code> Another not so obfuscated one is this: #import std.stdio; #void main() #{ # for(int i=0; i<10; i++) # (cast(void delegate()) # { # writef("foo"); # return; # } # )(); #} The point is that there could end up being some confusion as to weather something is a function or just a block. I think that the last rule gos a bit to far. Typing in the "()" doesn't cost much and adds a bunch as far as readability goes. FunctionLiteral function Typeopt ( ArgumentList )opt FunctionBody delegate Typeopt ( ArgumentList )opt FunctionBody ( ArgumentList ) FunctionBody
	FunctionBody


Jun 21 2006
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
About this literal delegate syntax, there seems to be an ambiguity:
    void delegate() foo = { }; // Thinks it's a struct initializer.
    void delegate() foo = ( { } ); // Workaround.
Jun 20 2006
prev sibling next sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
Walter Bright schrieb:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

Thanks. Especially for 106.
Jun 20 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

Great update, lots of bugfixes, and the shorter delegate syntax looks awesome! It says "Fixed Bugzilla 53 according to Bruno's analysis" but I don't know anything about bug 53. Did you meant Oskar, or perhaps bug 47? -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Great update, lots of bugfixes, and the shorter delegate syntax looks awesome! It says "Fixed Bugzilla 53 according to Bruno's analysis" but I don't know anything about bug 53. Did you meant Oskar, or perhaps bug 47?

It wasn't 53, but I can't remember which one it was!
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Walter Bright wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Great update, lots of bugfixes, and the shorter delegate syntax looks awesome! It says "Fixed Bugzilla 53 according to Bruno's analysis" but I don't know anything about bug 53. Did you meant Oskar, or perhaps bug 47?

It wasn't 53, but I can't remember which one it was!

Ah, it was #51.
Jun 20 2006
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

 Added opIn_r operator overload.

Excellent! I have just the use for that in this Python thing...
 New function template syntax.

So now that it's documented, it's here to stay and I can feel safe playing with it? Cool. -Kirk McDonald
Jun 20 2006
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

New delegate syntax looks great, can't wait to try it! -DavidM
Jun 20 2006
parent reply Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
David Medlock wrote:

 Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

New delegate syntax looks great, can't wait to try it!

Excellent. It's good to see that Walter likes many of the good features in Ruby. Some Java/C++ -fanboys might say that they're pure syntactic sugar, but trust me - they have lost their sanity long time ago ;) -- Jari-Matti
Jun 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jari-Matti Mäkelä wrote:
 David Medlock wrote:
 
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


Excellent. It's good to see that Walter likes many of the good features in Ruby. Some Java/C++ -fanboys might say that they're pure syntactic sugar, but trust me - they have lost their sanity long time ago ;)

It's possible to go too far with conciseness (APL and Perl show that!), but in general being able to write what you mean with a minimum of fuss makes for a more productive language.
Jun 20 2006
parent Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:
 Jari-Matti Mäkelä wrote:
 David Medlock wrote:
 New delegate syntax looks great, can't wait to try it!

Excellent. It's good to see that Walter likes many of the good features in Ruby. Some Java/C++ -fanboys might say that they're pure syntactic sugar, but trust me - they have lost their sanity long time ago ;)

It's possible to go too far with conciseness (APL and Perl show that!), but in general being able to write what you mean with a minimum of fuss makes for a more productive language.

I like most of the new features in D. They are both efficient and productive and still quite easy to use. Other than array literals and some polishing of interfaces, imports and templates there is not much left to make D the next king in it's class. I'm more than grateful for the experience I've had exploring the world of D. -- Jari-Matti
Jun 21 2006
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

Thanks, Walter :) Nice list of bug fixes ! I also dig the new features :D -- Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Jun 20 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

"Shadowing local variable declarations is now deprecated." I thought it had always been illegal by the spec. "Folded in D.bugs/7509" You seem to have slipped up here: "What's needed is an error handling philosophy and methodology such that: [...] * 'Quick and dirty' utilities to be written that still correctly handle errors." s/to/can "Fixed Bugzilla 57 in 0.151" Why is this in the changelog for 0.161? "Fixed Bugzilla 36 (better error message)" "Fixed Bugzilla 85 (now issues error message)" And they're also marked as fixed in Bugzilla. However, at the moment I can't seem to find the bit of the spec that indicates that either is illegal code. Stewart.
Jun 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

"Shadowing local variable declarations is now deprecated." I thought it had always been illegal by the spec.

It wasn't implemented.
 "Folded in D.bugs/7509"
 
 You seem to have slipped up here:
 
 "What's needed is an error handling philosophy and methodology such that:
 [...]
     * 'Quick and dirty' utilities to be written that still correctly 
 handle errors."
 
 s/to/can

Thanks, I'll fix.
 
 "Fixed Bugzilla 57  in 0.151"
 
 Why is this in the changelog for 0.161?

It was overlooked.
 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"
 
 And they're also marked as fixed in Bugzilla.  However, at the moment I 
 can't seem to find the bit of the spec that indicates that either is 
 illegal code.

36: forward references are an ongoing issue, I'd like to get rid of all such errors. But in the meantime, having feet of clay, some will give error messages instead. 85: It can't be made to work, because an interface handle is different from a class handle. It doesn't work in C++, either, for the same reasons.
Jun 20 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 
 "Fixed Bugzilla 85  (now issues error message)"

85: It can't be made to work, because an interface handle is different from a class handle. It doesn't work in C++, either, for the same reasons.

Anyway to get a cast? (If it is already there...) Somthing like: interface I{...} class C : I {...} ... C[] c; I[] i; c = ....; i = cast(I)c; // same as i.length = c.length; foreach(int j, C e; c) i[j] = (null !is e)?e:null;
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
BCS wrote:
 Walter Bright wrote:
 Stewart Gordon wrote:
 "Fixed Bugzilla 85  (now issues error message)"

85: It can't be made to work, because an interface handle is different from a class handle. It doesn't work in C++, either, for the same reasons.

Anyway to get a cast? (If it is already there...) Somthing like: interface I{...} class C : I {...} ... C[] c; I[] i; c = ....; i = cast(I)c; // same as i.length = c.length; foreach(int j, C e; c) i[j] = (null !is e)?e:null;

You'll have to iterate over the loop and cast each element.
Jun 20 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:

 85: It can't be made to work, because an interface handle is different 
 from a class handle. It doesn't work in C++, either, for the same reasons.

But it can be made to work, because an interface handle could be the same as a class handle. It works that way in Java, and is _far_ more useful, even if performance of method calls is reduced slightly. But we talked about that already, and I don't suppose you'll change your mind this time.. xs0
Jun 21 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
xs0 wrote:
 Walter Bright wrote:
 
 85: It can't be made to work, because an interface handle is different 
 from a class handle. It doesn't work in C++, either, for the same 
 reasons.

But it can be made to work, because an interface handle could be the same as a class handle. It works that way in Java, and is _far_ more useful, even if performance of method calls is reduced slightly. But we talked about that already, and I don't suppose you'll change your mind this time..

Java makes it "work" by doing runtime manipulation of interface/class handles whenever they are used. This is too inefficient for a native compiled language. Consider this: int can be implicitly converted to long. Therefore, shouldn't int[] be usable as a long[]? It's an exactly analogous situation.
Jun 21 2006
next sibling parent BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 xs0 wrote:
 
 Walter Bright wrote:

 85: It can't be made to work, because an interface handle is 
 different from a class handle. It doesn't work in C++, either, for 
 the same reasons.

But it can be made to work, because an interface handle could be the same as a class handle. It works that way in Java, and is _far_ more useful, even if performance of method calls is reduced slightly. But we talked about that already, and I don't suppose you'll change your mind this time..

Java makes it "work" by doing runtime manipulation of interface/class handles whenever they are used. This is too inefficient for a native compiled language. Consider this: int can be implicitly converted to long. Therefore, shouldn't int[] be usable as a long[]? It's an exactly analogous situation.

A user code solution could be used: T[] castArray(F, T)(F[] array) { T[] ret = new T[array.length]; foreach(i,e;array) { // this is from memory, but you get the picture static if(is(T : Object)) (e!is null) ? ret[i]=e; ? ret[i]=null; else ret[i]=e; } return ret; } void main() { const static int[] from = [1,2,3,4,5,6,7,8,9]; long[] to = castArray!(int, long)(from); }
Jun 21 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:
 xs0 wrote:
 Walter Bright wrote:

 85: It can't be made to work, because an interface handle is 
 different from a class handle. It doesn't work in C++, either, for 
 the same reasons.

But it can be made to work, because an interface handle could be the same as a class handle. It works that way in Java, and is _far_ more useful, even if performance of method calls is reduced slightly. But we talked about that already, and I don't suppose you'll change your mind this time..

Java makes it "work" by doing runtime manipulation of interface/class handles whenever they are used.

Well, I think it's quite irrelevant what Java does (and the same goes for C++*), the question is what is a better option, where we seem to disagree.
 This is too inefficient for a native 
 compiled language.

I (still) think you're over-exaggerating the efficiency issue, because the difference is not that large in reality. For anything but the simplest methods the speed penalty is practically negligible (I measured it), and it's not the simplest methods that most time is spent on, I'd say. And you could use the same argument against virtual methods, but you still implemented them.
 Consider this:
 
   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?
 
 It's an exactly analogous situation.

No, it isn't. int is of a different "class" than long, while an interface reference and a class reference point to exactly the same object. You also seem to miss the reduced complexity of implementation (a stated goal I believe). With a simple double lookup, interfaces can be handled in a single place, and I'd guess you could implement that very easily just by faking another calling convention. On the other hand, if interface references point to a different address than class references, you need to store offsets somewhere, have to modify the address on every call, need to handle implicit conversions when passing function boundaries, etc. etc. xs0 *) Note that C++ supports MI, meaning double lookup would hurt every method call. Otoh, in D we'd get to keep the speed of non-interface calls.
Jun 21 2006
next sibling parent reply BenHinkle <BenHinkle_member pathlink.com> writes:
 Consider this:
 
   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?
 
 It's an exactly analogous situation.

No, it isn't. int is of a different "class" than long, while an interface reference and a class reference point to exactly the same object. You also seem to miss the reduced complexity of implementation (a stated goal I believe). With a simple double lookup, interfaces can be handled in a single place, and I'd guess you could implement that very easily just by faking another calling convention.

Can you explain more what you mean by double lookup? I'm not aware of that technique.
On the other hand, if interface references point to a different address 
than class references, you need to store offsets somewhere, have to 
modify the address on every call, need to handle implicit conversions 
when passing function boundaries, etc. etc.

This technique I'm used to. It's called thunking and I believe it's the standard way of implementing MI and/or interfaces. That is, when a class implements an interface method it makes a thunk to adjust the 'this' pointer before calling the actual class method. So when you have an interface A and class C and call a method f in A that is implemented in C the slot in the vtable for f (which takes an A) calls the thunk to adjust the A to a C and then the thunk jumps to the method (which takes a C). -Ben
Jun 21 2006
parent reply xs0 <xs0 xs0.com> writes:
BenHinkle wrote:
 Consider this:

   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?

 It's an exactly analogous situation.

interface reference and a class reference point to exactly the same object. You also seem to miss the reduced complexity of implementation (a stated goal I believe). With a simple double lookup, interfaces can be handled in a single place, and I'd guess you could implement that very easily just by faking another calling convention.

Can you explain more what you mean by double lookup? I'm not aware of that technique.

It's very simple :)
 iref.someFunction(...) // iref is an interface reference

becomes
 iref.getVtbl(SomeInterface.classinfo)[2](iref, ...)

instead of the current
 iref.someFunction(iref-offset, ...)

I tested speed of various calling methods with http://www.xs0.com/d/ifaces.d.html and here are the results I get: Normal: 12165450 / sec Through interface: 11764706 / sec Lookup every time: 9580379 / sec Optimized lookup: 13390466 / sec Static functions: 13224015 / sec The number is function calls / second. With a function of any significant complexity, the differences would be even smaller, and even here it's just around 20% in the worst case. And if a simple observation* is implemented in the optimizer, the speed loss in fact becomes speed gain (ok, in reality it would also be implemented for non-interface methods, so the speed would end up the same). *) if the object reference doesn't change neither can the function pointer
 On the other hand, if interface references point to a different address 
 than class references, you need to store offsets somewhere, have to 
 modify the address on every call, need to handle implicit conversions 
 when passing function boundaries, etc. etc.

This technique I'm used to. It's called thunking and I believe it's the standard way of implementing MI and/or interfaces. That is, when a class implements an interface method it makes a thunk to adjust the 'this' pointer before calling the actual class method. So when you have an interface A and class C and call a method f in A that is implemented in C the slot in the vtable for f (which takes an A) calls the thunk to adjust the A to a C and then the thunk jumps to the method (which takes a C).

Well, I think there's a significant difference between MI and interfaces in that interfaces only allow methods, while with MI you also have fields to think of. Having to basically make a function call for each field access would indeed be too inefficient, but it's not the same case with methods, because the call itself usually takes only a (very) small part of total method execution time. xs0
Jun 22 2006
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 I tested speed of various calling methods with
 http://www.xs0.com/d/ifaces.d.html

 and here are the results I get:

               Normal:             12165450 / sec
    Through interface:             11764706 / sec
    Lookup every time:              9580379 / sec
     Optimized lookup:             13390466 / sec
     Static functions:             13224015 / sec

 The number is function calls / second.

 With a function of any significant complexity, the differences would be 
 even smaller, and even here it's just around 20% in the worst case. And if 
 a simple observation* is implemented in the optimizer, the speed loss in 
 fact becomes speed gain (ok, in reality it would also be implemented for 
 non-interface methods, so the speed would end up the same).

 *) if the object reference doesn't change neither can the function pointer

ok, I see what you mean. thanks for explaining. Pretty cool! Since the vtable lookup is linear in the total number of interfaces the class implements (including the interfaces of super-interfaces) it could be more noticeable in larger examples.
 On the other hand, if interface references point to a different address 
 than class references, you need to store offsets somewhere, have to 
 modify the address on every call, need to handle implicit conversions 
 when passing function boundaries, etc. etc.

This technique I'm used to. It's called thunking and I believe it's the standard way of implementing MI and/or interfaces. That is, when a class implements an interface method it makes a thunk to adjust the 'this' pointer before calling the actual class method. So when you have an interface A and class C and call a method f in A that is implemented in C the slot in the vtable for f (which takes an A) calls the thunk to adjust the A to a C and then the thunk jumps to the method (which takes a C).

Well, I think there's a significant difference between MI and interfaces in that interfaces only allow methods, while with MI you also have fields to think of. Having to basically make a function call for each field access would indeed be too inefficient, but it's not the same case with methods, because the call itself usually takes only a (very) small part of total method execution time.

In general I agree function call speed isn't a big deal for interfaces but it isn't unusual to have an interface that abstracts out a field lookup (eg, getLength). For those the body of the implementation would be very simple. I'm curious if the double lookup technique has been tried in practice and what the impressions were.
Jun 22 2006
next sibling parent Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
Ben Hinkle wrote:
 In general I agree function call speed isn't a big deal for interfaces but
 it isn't unusual to have an interface that abstracts out a field lookup
 (eg, getLength). For those the body of the implementation would be very
 simple. I'm curious if the double lookup technique has been tried in
 practice and what the impressions were.

Does any commonly used language / compiler implement these double lookups? Like xs0 said, the decrease in overall speed is ridiculously small. Most (non-pro guru) Java programmers I know of use interfaces this way a lot despite the obvious drawbacks in performance. I think that beefing up the compiler logic just a little bit here pays itself back faster than we can even imagine. At least it makes the life of application programmers and thus end users a bit easier (better modularity, less error-prone casting). To me it sounds a bit weird that Walter has promised to implement array literals, but interfaces are going to be left broken. They're can be both implemented now by using template hacks and seem to be equally hard to implement. -- Jari-Matti
Jun 22 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
Ben Hinkle wrote:
 ok, I see what you mean. thanks for explaining. Pretty cool! Since the 
 vtable lookup is linear in the total number of interfaces the class 
 implements (including the interfaces of super-interfaces) it could be more 
 noticeable in larger examples.

Well, the lookup need not be linear. Since the interfaces are known in advance for each class, it should be possible to achieve a fast O(1) lookup with something like a [minimal] perfect hash function, all you'd probably need is some sort of numeric identifier for each interface (could simply be a MD5 of its full name or something).
 In general I agree function call speed isn't a big deal for interfaces but 
 it isn't unusual to have an interface that abstracts out a field lookup (eg, 
 getLength). For those the body of the implementation would be very simple. 
 I'm curious if the double lookup technique has been tried in practice and 
 what the impressions were.

Well, as far as I can tell, Sun's JVM does something like this (at least the timing results seem to suggest so), and considering how often interfaces get used in Java, I'd say it's not actually a significant problem. Though I've no idea if any compiled language does so, as I don't know that many :) It should also be noted that having a single reference to each object would allow covariance in many more cases, so it'd be easier to actually have a class reference than it is now.. xs0
Jun 22 2006
parent BCS <BCS pathlink.com> writes:
xs0 wrote:
 Ben Hinkle wrote:
 
 ok, I see what you mean. thanks for explaining. Pretty cool! Since the 
 vtable lookup is linear in the total number of interfaces the class 
 implements (including the interfaces of super-interfaces) it could be 
 more noticeable in larger examples.

Well, the lookup need not be linear. Since the interfaces are known in advance for each class, it should be possible to achieve a fast O(1) lookup with something like a [minimal] perfect hash function, all you'd probably need is some sort of numeric identifier for each interface (could simply be a MD5 of its full name or something).

I would expect that the pointer-to-vtbl for the interface would be placed in the classes vtbl. class to interface cast would consist of (in sudo code) /** i = c; **/ interface_Ijk_Struct i; with (i) { contextPtr = c; vtbl = c.vtbl[Ijk_Vtbl]; } ////// What am I missing?
Jun 22 2006
prev sibling parent BenHinkle <BenHinkle_member pathlink.com> writes:
 Consider this:
 
   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?
 
 It's an exactly analogous situation.

No, it isn't. int is of a different "class" than long, while an interface reference and a class reference point to exactly the same object. You also seem to miss the reduced complexity of implementation (a stated goal I believe). With a simple double lookup, interfaces can be handled in a single place, and I'd guess you could implement that very easily just by faking another calling convention.

Can you explain more what you mean by double lookup? I'm not aware of that technique.
On the other hand, if interface references point to a different address 
than class references, you need to store offsets somewhere, have to 
modify the address on every call, need to handle implicit conversions 
when passing function boundaries, etc. etc.

This technique I'm used to. It's called thunking and I believe it's the standard way of implementing MI and/or interfaces. That is, when a class implements an interface method it makes a thunk to adjust the 'this' pointer before calling the actual class method. So when you have an interface A and class C and call a method f in A that is implemented in C the slot in the vtable for f (which takes an A) calls the thunk to adjust the A to a C and then the thunk jumps to the method (which takes a C). -Ben
Jun 21 2006
prev sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <e7bv51$9lp$1 digitaldaemon.com>, Walter Bright says...

[...]
Consider this:

   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?

It's an exactly analogous situation.

I agree. To make it simple you can do like this: template copycast (T : T[]) { T[] copycast (X) (X[] array) { T[] retVal = new T[array.length]; foreach (int i, X elem; array) { retVal[i] = cast(T) elem; } return retVal; } } int main() { int[] a = new int[10]; long[] al = copycast!(long[]) (a); interface I { } class A : I { } A[] array = new A[10]; I[] dest = copycast!(I[]) (array); return 0; } Ciao --- http://www.mariottini.net/roberto/
Jun 22 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

"Shadowing local variable declarations is now deprecated." I thought it had always been illegal by the spec.

It wasn't implemented.

So you've implemented it as a deprecation for the time being, rather than banning it altogether? <snip>
 "Fixed Bugzilla 57  in 0.151"

 Why is this in the changelog for 0.161?

It was overlooked.

What do you mean? The changelog for 0.151 also lists this bug as fixed.
 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"

 And they're also marked as fixed in Bugzilla.  However, at the moment 
 I can't seem to find the bit of the spec that indicates that either is 
 illegal code.

36: forward references are an ongoing issue, I'd like to get rid of all such errors. But in the meantime, having feet of clay, some will give error messages instead.

Nobody else I know would claim that changing the error message resulting from a bug constitutes fixing the bug. If the bug _is_ the bad error message, rather than the fact that an error is produced at all, then that's another matter.
 85: It can't be made to work, because an interface handle is different 
 from a class handle.

But it can be made to create a new array of the interface type. But this should probably require an explicit cast. Just looking at the documentation, the "Implicit Conversions" section of arrays.html mentions "U[] where U is a base class of T" - I now suppose it's just a temptation to think that it would work on interfaces as well. Clarification would certainly be welcome. And we could also do with some decent documentation on what arrays may be converted to by explicit casting.
 It doesn't work in C++, either, for the same reasons.

Since when has C++ had interfaces? Stewart.
Jun 22 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:

 Walter Bright wrote:
 Stewart Gordon wrote:
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

"Shadowing local variable declarations is now deprecated." I thought it had always been illegal by the spec.

It wasn't implemented.

So you've implemented it as a deprecation for the time being, rather than banning it altogether?

Walter's actions here made sense to me. A lot of people had begun to think that the bug lay in the documentation and not the implementation, and so coded accordingly. Now, rather than force them to immediately change all their source code, Walter has allowed them a way to gradually convert to the real specification.
 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"

 And they're also marked as fixed in Bugzilla.  However, at the moment 
 I can't seem to find the bit of the spec that indicates that either is 
 illegal code.

36: forward references are an ongoing issue, I'd like to get rid of all such errors. But in the meantime, having feet of clay, some will give error messages instead.

Nobody else I know would claim that changing the error message resulting from a bug constitutes fixing the bug.

It could be argued that #36 remain as 'open' so that the underlying bug is eventually fixed. However, now that the message text has changed (improved?) it might be better for us to open a new bug entry, using the new message in the commentary, to keep this issue on Walter's TODO list.
 And we could also do with some decent documentation on what arrays may 
 be converted to by explicit casting.

As you may have noticed, Walter often gets a bit busy. It might then be a reasonable idea for you, or anyone else, to have a go at writing this documentation update and sending it to Walter for merging into the main documentation body. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 23/06/2006 9:17:40 AM
Jun 22 2006
parent reply BCS <BCS pathlink.com> writes:
Derek Parnell wrote:
 On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:

 
And we could also do with some decent documentation on what arrays may 
be converted to by explicit casting.

As you may have noticed, Walter often gets a bit busy. It might then be a reasonable idea for you, or anyone else, to have a go at writing this documentation update and sending it to Walter for merging into the main documentation body.

How do you get DMD to let you use depreciated "things"? I know it's in there somewhere but I can't seem to find the switch.
Jun 22 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:

 Derek Parnell wrote:
 On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:

 
And we could also do with some decent documentation on what arrays may 
be converted to by explicit casting.

As you may have noticed, Walter often gets a bit busy. It might then be a reasonable idea for you, or anyone else, to have a go at writing this documentation update and sending it to Walter for merging into the main documentation body.

How do you get DMD to let you use depreciated "things"? I know it's in there somewhere but I can't seem to find the switch.

Use the "-d" switch. Documented under "Tools / DMD D Compiler" -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 23/06/2006 10:28:15 AM
Jun 22 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:
 On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:
 
 Derek Parnell wrote:
 On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:

 And we could also do with some decent documentation on what arrays may 
 be converted to by explicit casting.

reasonable idea for you, or anyone else, to have a go at writing this documentation update and sending it to Walter for merging into the main documentation body.

there somewhere but I can't seem to find the switch.

Use the "-d" switch. Documented under "Tools / DMD D Compiler"

And under the dmd command line help. BCS, that was hard to miss. *g* -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 23 2006
parent BCS <BCS pathlink.com> writes:
Bruno Medeiros wrote:
 Derek Parnell wrote:
 
 On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:

 How do you get DMD to let you use depreciated "things"? I know it's 
 in there somewhere but I can't seem to find the switch.

Use the "-d" switch. Documented under "Tools / DMD D Compiler"

And under the dmd command line help. BCS, that was hard to miss. *g*

I'm blind, BLIND I TELL YOU!! :-p "The easy way to find the answer to a question is ask someone who knows. Usually you will figure it out yourself about half a second before they stop smirking and tell you." --B... er Anon.
Jun 23 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Stewart Gordon wrote:
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

"Shadowing local variable declarations is now deprecated." I thought it had always been illegal by the spec.

It wasn't implemented.

So you've implemented it as a deprecation for the time being, rather than banning it altogether?

Yes, because it breaks a lot of existing code.
 "Fixed Bugzilla 57  in 0.151"

 Why is this in the changelog for 0.161?

It was overlooked.

What do you mean? The changelog for 0.151 also lists this bug as fixed.

Yes, but it was left open in bugzilla.
 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"

 And they're also marked as fixed in Bugzilla.  However, at the moment 
 I can't seem to find the bit of the spec that indicates that either 
 is illegal code.

36: forward references are an ongoing issue, I'd like to get rid of all such errors. But in the meantime, having feet of clay, some will give error messages instead.

Nobody else I know would claim that changing the error message resulting from a bug constitutes fixing the bug. If the bug _is_ the bad error message, rather than the fact that an error is produced at all, then that's another matter.

Giving clear error messages takes care of the problem for now.
 85: It can't be made to work, because an interface handle is different 
 from a class handle.

But it can be made to create a new array of the interface type. But this should probably require an explicit cast. Just looking at the documentation, the "Implicit Conversions" section of arrays.html mentions "U[] where U is a base class of T" - I now suppose it's just a temptation to think that it would work on interfaces as well. Clarification would certainly be welcome. And we could also do with some decent documentation on what arrays may be converted to by explicit casting.
 It doesn't work in C++, either, for the same reasons.


Multiple inheritance is a superset of interfaces.
Jun 22 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

thanks!
Jun 20 2006
prev sibling next sibling parent daniel.keep.lists gmail.com writes:
In article <e7832r$g4h$1 digitaldaemon.com>, Walter Bright says...
Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html

Once again, you rock. Thanks very much for this :)
Jun 20 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e7832r$g4h$1 digitaldaemon.com...
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Oh man, those delegate literals look like it would be very possible to make interesting "pseudo-structures," that is, fake language constructs. So if you were to define a function as void func(void delegate() dg); That is, the last parameter is a void delegate(), it would be an interesting bit of syntactic sugar to be able to write func { writefln("foo"); } Not sure what utility this would present, but hey!
Jun 20 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Oh man, those delegate literals look like it would be very possible to make interesting "pseudo-structures," that is, fake language constructs. So if you were to define a function as void func(void delegate() dg); That is, the last parameter is a void delegate(), it would be an interesting bit of syntactic sugar to be able to write func { writefln("foo"); } Not sure what utility this would present, but hey!

There was some thought about doing that, but I'm not so sure it wouldn't be more confusing than useful.
Jun 20 2006
next sibling parent reply Rémy Mouëza <Rémy_member pathlink.com> writes:
The new delegate syntax reminds me Smalltalk's code blocks. As far as I
remember, Ruby also uses code blocks with a syntax using braces rather than
bracket.

Smalltalk: 
collection do:[ :each | Transcript show: each asString ; cr. ].

D:
collection.do (( Object each ){ writefln ( each ); });
( a foreach would be preferrable in that case, but it's just to notice the
similarities ). 

D is getting greater and greater. Thanks Walter !!!
Jun 20 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Rémy Mouëza" <Rémy_member pathlink.com> wrote in message 
news:e79hbc$2tul$1 digitaldaemon.com...


 Smalltalk:
 collection do:[ :each | Transcript show: each asString ; cr. ].

 D:
 collection.do (( Object each ){ writefln ( each ); });
 ( a foreach would be preferrable in that case, but it's just to notice the
 similarities ).

That is an awesome comparison.
Jun 20 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e79d2a$2o0c$2 digitaldaemon.com...

 There was some thought about doing that, but I'm not so sure it wouldn't 
 be more confusing than useful.

Hehe, how true. But hey, check it out: void foo(void delegate() dg) { writefln("before"); dg(); } foo = { writefln("inside!"); }; A bit of property abuse..
Jun 20 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Jun 2006 21:12:22 -0400, Jarrett Billingsley wrote:

 But hey, check it out:
 
 void foo(void delegate() dg)
 {
     writefln("before");
     dg();
 }
 
 foo =
 {
     writefln("inside!");
 };
 
 A bit of property abuse..

LOL ... Here is an extended test ... import std.stdio; void foo(void delegate() dg) { writefln("before"); dg(); writefln("after\n"); } void main(char[][] arg) { char[] str; void bar() { writefln(arg[0] ~ ":" ~ str); } foo = { writefln("inside!"); }; foo = { writefln("again!"); }; foo( {writefln("last time");} ); str = "not really"; foo(&bar); str = "RUBBISH"; foo = &bar; } -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 21/06/2006 12:40:50 PM
Jun 20 2006
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Oh man, those delegate literals look like it would be very possible to make interesting "pseudo-structures," that is, fake language constructs. So if you were to define a function as void func(void delegate() dg); That is, the last parameter is a void delegate(), it would be an interesting bit of syntactic sugar to be able to write func { writefln("foo"); } Not sure what utility this would present, but hey!

There was some thought about doing that, but I'm not so sure it wouldn't be more confusing than useful.

With the new delegate syntax, and a very simple function one can finally replace the annoying and common case where a for-loop until now still has to be used: void repeat(Int,Delegate)(Int n, Delegate d) { static assert(is(Int:int),"Argument 1 to repeat must be int"); for (int i = 0; i < n; i++) d(); } The implementation could also contain: static if (NumberOfArgs!(Delegate) == 1) d(i); The use is: repeat(10, { something(); }); And the multi-line version becomes: repeat(10, { something(); somethingElse(); }); Which at least makes me wish for Jarretts suggested short form: repeat(10) { something(); somethingElse(); } But the implications of having such power is almost scary... :) /Oskar
Jun 29 2006
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Oskar Linde wrote:
 Which at least makes me wish for Jarretts suggested short form:
 
 repeat(10) {
   something();
   somethingElse();
 }

But that's exactly what foreach does, isn't it? Would be cool if that construct would be made available to user functions! L.
Jun 29 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Oskar Linde wrote:
 Walter Bright wrote:
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Oh man, those delegate literals look like it would be very possible to make interesting "pseudo-structures," that is, fake language constructs. So if you were to define a function as void func(void delegate() dg); That is, the last parameter is a void delegate(), it would be an interesting bit of syntactic sugar to be able to write func { writefln("foo"); } Not sure what utility this would present, but hey!

There was some thought about doing that, but I'm not so sure it wouldn't be more confusing than useful.

With the new delegate syntax, and a very simple function one can finally replace the annoying and common case where a for-loop until now still has to be used: void repeat(Int,Delegate)(Int n, Delegate d) { static assert(is(Int:int),"Argument 1 to repeat must be int"); for (int i = 0; i < n; i++) d(); } The implementation could also contain: static if (NumberOfArgs!(Delegate) == 1) d(i); The use is: repeat(10, { something(); }); And the multi-line version becomes: repeat(10, { something(); somethingElse(); }); Which at least makes me wish for Jarretts suggested short form: repeat(10) { something(); somethingElse(); } But the implications of having such power is almost scary... :) /Oskar

That's too much power for us puny mortals! :P -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 01 2006
prev sibling parent reply David Medlock <noone nowhere.com> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...
 
Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html

Oh man, those delegate literals look like it would be very possible to make interesting "pseudo-structures," that is, fake language constructs. So if you were to define a function as void func(void delegate() dg); That is, the last parameter is a void delegate(), it would be an interesting bit of syntactic sugar to be able to write func { writefln("foo"); } Not sure what utility this would present, but hey!

Deja Vu? http://www.digitalmars.com/d/archives/digitalmars/D/24770.html hehe.
Jun 29 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"David Medlock" <noone nowhere.com> wrote in message 
news:e818mk$fcj$2 digitaldaemon.com...

 Deja Vu?

 http://www.digitalmars.com/d/archives/digitalmars/D/24770.html

 hehe.

Heh, I thought I remembered that!
Jun 29 2006
prev sibling next sibling parent reply Jeremy <Jeremy_member pathlink.com> writes:
In article <e7832r$g4h$1 digitaldaemon.com>, Walter Bright says...
Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html

This post might be more useful in here, because I think it might be a bug in the latest v0.161 release, and I wanted to get Walter's attention :) digitalmars.D/39132
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Jeremy wrote:
 This post might be more useful in here, because I think it might be a bug in
the
 latest v0.161 release, and I wanted to get Walter's attention :)
 
 digitalmars.D/39132

I need a small, reproducible example.
Jun 20 2006
prev sibling next sibling parent reply Vladimir <vlasov scatt.com> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

Nice work, Walter. Thank you. I hoped the following code will not compile with .161 #struct A #{ # int x; #} # #void main() #{ # A a; # with(a) { # int x; // compiles without error # } #} Vladimir
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Vladimir wrote:
 Walter Bright wrote:
 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html

Nice work, Walter. Thank you. I hoped the following code will not compile with .161 #struct A #{ # int x; #} # #void main() #{ # A a; # with(a) { # int x; // compiles without error # } #}

A.x is a field, not a local variable, so the shadowing rule doesn't apply.
Jun 20 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

WOW! (For everything) :)
Jun 23 2006