Re: foreach and retro
"bearophile" , dans le message (digitalmars.D:171013), a écrit : > It's not a bug, it's caused by how ranges like retro work. retro > yields a single item. In D you can't overload on return values, But you can overload OpApply. -- Christophe
Re: Two Scala annotations
On 7/2/2012 1:04 PM, bearophile wrote: Walter Bright: Put "final" in front of y, and it will compile. Remember, this was done for D1 that didn't have const. I see. So in D2 are we going to require that y to be immutable? No. I don't agree there's a problem. Nor do I care to break existing D1 code (and D2 for that matter) without an awfully good reason, and I don't see one here.
Re: Two Scala annotations
Walter Bright: Put "final" in front of y, and it will compile. Remember, this was done for D1 that didn't have const. I see. So in D2 are we going to require that y to be immutable? Bye, bearophile
Re: Two Scala annotations
On 7/2/2012 7:37 AM, bearophile wrote:
I have compiled this Java code:
class Main {
public static void main(String[] args) {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
}
}
}
It gives:
Main.java:7: error: constant expression required
case y: break;
^
1 error
As you see:
http://ideone.com/wAXMZ
Put "final" in front of y, and it will compile. Remember, this was done for D1
that didn't have const.
Re: foreach and retro
D does not provide index for the range iteration.
Instead, you can create 'zipped' range.
void main() {
auto intr = sequence!"n"(); // 0, 1, 2, ...
double[] a = [ 0, 1, 2, 3, 4, 5 ];
foreach(i, x; zip(intr, retro(a)))
writeln(i, "\t", x);
}
zip(intr, retro(a)) is a range of Tuple!(size_t, double), and foreach
automatically expand the tow fields of zip front into i and x like
follows.
foreach(__e; zip(intr, retro(a))) {
auto i = __elem[0], x = __elem[1]; // inserted by the compiler
writeln(i, "\t", x);
}
After all, you can get 'index' for range iteration.
Kenji Hara
2012/7/3 Joseph Rushton Wakeling :
> On 02/07/12 17:48, Timon Gehr wrote:
>>
>> What would be your expected output?
>
>
> I'd expect to see
>
> 0 5
> 1 4
> 2 3
> 3 2
> 4 1
> 5 0
>
> i.e. as if I was foreach-ing over an array with the same values in inverted
> order.
Re: foreach and retro
On Monday, 2 July 2012 at 16:49:06 UTC, Joseph Rushton Wakeling
wrote:
On 02/07/12 17:48, Timon Gehr wrote:
What would be your expected output?
I'd expect to see
0 5
1 4
2 3
3 2
4 1
5 0
i.e. as if I was foreach-ing over an array with the same values
in inverted order.
Use the .array() property:
auto Range(alias func, Args...)(Args args) {
return func(args).array();
}
void main() {}
double[] ad = [ 0, 1, 2, 3, 4, 5 ];
foreach(index, x; Range!(retro)(ad)) {
writeln(index, "\t", x);
}
}
Re: foreach and retro
On 02/07/12 17:48, Timon Gehr wrote: What would be your expected output? I'd expect to see 0 5 1 4 2 3 3 2 4 1 5 0 i.e. as if I was foreach-ing over an array with the same values in inverted order.
Re: foreach and retro
Joseph Rushton Wakeling: double[] a = [ 0, 1, 2, 3, 4, 5 ]; foreach(i, x; retro(a)) writeln(i, "\t", x); It's not a bug, it's caused by how ranges like retro work. retro yields a single item. In D you can't overload on return values, so foreach can't try to call a second retro.front overload that yields an (index,item) tuple (that later foreach is able to unpack on the fly) instead of the retro.front that just yields the item. To solve that problem this is what I have suggested to add to Phobos: http://d.puremagic.com/issues/show_bug.cgi?id=5550 Bye, bearophile
Re: foreach and retro
What would be your expected output? From the inner to the outer expression: First the range is reversed and then the elements of this range are enumerated.
Re: foreach and retro
On 07/02/2012 05:36 PM, Joseph Rushton Wakeling wrote:
Hello all,
A problem with the retro function from std.range -- although it
apparently operates on a bidirectional range, it fails when used with
foreach requesting both value and index. Running this code:
import std.range, std.stdio;
void main()
{
double[] a = [ 0, 1, 2, 3, 4, 5 ];
foreach(i, x; retro(a))
writeln(i, "\t", x);
}
... results in an error: "cannot infer argument types".
Is there any reason why this should be so, or is it (as it seems to me)
just a bug?
Thanks & best wishes,
-- Joe
What would be your expected output?
Re: foreach and retro
Running this code Sorry, should be "attempting to compile this code".
foreach and retro
Hello all,
A problem with the retro function from std.range -- although it apparently
operates on a bidirectional range, it fails when used with foreach requesting
both value and index. Running this code:
import std.range, std.stdio;
void main()
{
double[] a = [ 0, 1, 2, 3, 4, 5 ];
foreach(i, x; retro(a))
writeln(i, "\t", x);
}
... results in an error: "cannot infer argument types".
Is there any reason why this should be so, or is it (as it seems to me) just a
bug?
Thanks & best wishes,
-- Joe
Re: Two Scala annotations
Don Clugston:
Do you have a reference for this Java behaviour? I did a quick
google, and everything I found indicates that case labels must
be constants.
Thank you for your answer, Don.
I have compiled this Java code:
class Main {
public static void main(String[] args) {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
}
}
}
It gives:
Main.java:7: error: constant expression required
case y: break;
^
1 error
As you see:
http://ideone.com/wAXMZ
Bye,
bearophile
Re: Two Scala annotations
On 01/07/12 04:00, Walter Bright wrote: On 6/30/2012 6:05 PM, bearophile wrote: Walter Bright: It's not a bug. It's deliberate, and is there to support mechanical translation of Java code. Is this stuff written somewhere in a D design rationales page? Now that D is several years old, how much Java code was ported to D? (Despite there is no mechanical Java->D translator yet). Yes, a mechanical translator was used extensively to create dwt. Was this automatic translation desire worth the troubles (like inner classes, Yes. like the risk of killing switch optimizations by mistake)? Calling it a "risk" and "killing" is way, way overstating things. This post is about two Scala annotations. If that's not a bug, is something like that first Scala annotation useful in D too? I don't really see any problem requiring a solution. If you're working on optimizations at that level, you ought to be comfortable examining the asm output for that and all the other stuff, too. Setting a store on just one aspect of switch implementations is a large mistake. The problem isn't the effect on optimization. The problem is that the semantics are insane. They are like nothing else in the language, and they don't make any sense. It's a very complicated feature: eg what happens if the case is a shared variable? Under what circumstances is a symbol treated as a variable, rather than a constant? As far as I know, no other language works anything like this. Either switch accepts only constants, or it accepts arbitrary expressions. Not this bizarre combination of both. Do you have a reference for this Java behaviour? I did a quick google, and everything I found indicates that case labels must be constants.
Re: foreach ref very broken: fails to call front(val)
On Monday, 2 July 2012 at 12:44:59 UTC, monarch_dodra wrote:
I think this is a pretty serious bug: when one writes:
"foreach(ref a, range)", the underlying (ref'd) object will
ONLY get modified if the range object provides a "ref T
front()" method.
Somethig related, zip(a,b) allows to sort the two arrys, but you
can't modify the arry items with a ref foreach:
import std.stdio: writeln;
import std.algorithm: sort;
import std.range: zip;
void foo1() {
auto a = [10, 20, 30];
auto b = [100, 200, 300];
foreach (ref x, y; zip(a, b))
x++;
writeln(a);
}
void foo2() {
int[] a = [1, 2, 3];
string[] b = ["c", "b", "a"];
writeln(zip(a, b)[2]);
writeln(a, "\n", b);
sort!("a[0] > b[0]")(zip(a, b));
writeln(a, "\n", b);
}
void main() {
foo1();
foo2();
}
Output:
[10, 20, 30]
Tuple!(int,string)(3, "a")
[1, 2, 3]
["c", "b", "a"]
[3, 2, 1]
["a", "b", "c"]
Bye,
bearophile
Re: Remove std.algorithm.completeSort.
My main point is that it doesn't work. Even the given example does not work. It should either be fixed or ditched.
Re: Is this statement in http://dlang.org/dmd-windows.html still true?
On 12-07-02 4:58 AM, Ali Çehreli wrote: On 07/01/2012 06:42 PM, Pierre Rouleau wrote: > Would the following rewrite of the above statement maintain the original > intent while conveying a little bit more information? > > "It is never a good idea to write into a string literal. "never a good idea" would be too permissive and welcoming. The documentation should simply say that writing into a string literal is undefined behavior (exactly like in other popular system languages like C and C++). The current documentation gets into unnecessary detail of what may happen and why under different environments. Well, yes. :) It is undefined behavior. Ali Thanks Ali, I completely agree. - Pierre Rouleau
Re: Remove std.algorithm.completeSort.
On 7/2/12 5:50 AM, Bernard Helyer wrote: Because it's apparent to me it's not going to be fixed. Furthermore, what does it gain you over sort(chain(a, b))? This is the first time in the 2 years it's been broken (and apparently Jesse is the only one that knew this! :D) someone has come to IRC with a problem regarding it. From that highly biased sample, I conclude it's not getting used. Anywhere. Or that bug would have more noise (it's the only result for 'completeSort' on bugzilla). http://d.puremagic.com/issues/show_bug.cgi?id=4936 It's a fairly specialized function, but we shouldn't draw conclusions about usefulness of library functions from current use alone. Andrei
Re: Excesive use of opIndex* in std.container.Array (and Ranges in general)
On 7/2/12 4:13 AM, monarch_dodra wrote: When I read the "D programming language" chapter on operator overloading, I found that the fact there were operators "opIndexAssign", "opIndexOpAssing" and "opIndexUnary" to be nothing short of brilliant. Finally, a container of bools that works for real! However, if and when "opIndex" is capable of returning a reference, isn't defining the above symbols gratuitous, error prone, and worse, actually restrictive? I agree. There should be an enhancement request for this. Andrei
Re: Creating a Sub-view of a non - RA (hasSlicing) range.
Have you had a look at dcollection ? http://www.dsource.org/projects/dcollections There is a doubly linked list implementation, with range and cursors (entities that have iterator functionalities).
Re: Forum for language feature requests?
On 07/02/2012 12:49 PM, Tommi wrote: I've made a couple of language feature requests: This & Super: http://forum.dlang.org/thread/csjqswdlermlnbjbx...@forum.dlang.org We already have this. typeof(this) and typeof(super). Improving pseudo function call syntax: http://forum.dlang.org/thread/uufohvapbyceuaylo...@forum.dlang.org This is not a feature request. It is a feature sketch at best. But... is this the correct forum for language feature requests? I can't help but think there should be a more dedicated place for those. Or is it already too late in the game to be even making language changing feature requests? You could post them as enhancement requests into the bug tracker.
Re: Forum for language feature requests?
On Monday, 2 July 2012 at 10:49:07 UTC, Tommi wrote: I've made a couple of language feature requests: This & Super: http://forum.dlang.org/thread/csjqswdlermlnbjbx...@forum.dlang.org Improving pseudo function call syntax: http://forum.dlang.org/thread/uufohvapbyceuaylo...@forum.dlang.org But... is this the correct forum for language feature requests? I can't help but think there should be a more dedicated place for those. Or is it already too late in the game to be even making language changing feature requests? You can write a DIP (D Improvement Proposal). Imo those should get mandatory for language changes and deserve more love, i.e. they should not rot but be either accepted or denied. (After vote or veto from Walter)
Re: dmd 2.060 ignoring ref for Array arguments
Done. http://d.puremagic.com/issues/show_bug.cgi?id=8335
Re: Remove std.algorithm.completeSort.
This is relatively tongue in cheek of course, but it _has_ been effectively deprecated since 2010. :P
Remove std.algorithm.completeSort.
Because it's apparent to me it's not going to be fixed. Furthermore, what does it gain you over sort(chain(a, b))? This is the first time in the 2 years it's been broken (and apparently Jesse is the only one that knew this! :D) someone has come to IRC with a problem regarding it. From that highly biased sample, I conclude it's not getting used. Anywhere. Or that bug would have more noise (it's the only result for 'completeSort' on bugzilla). http://d.puremagic.com/issues/show_bug.cgi?id=4936
Re: dmd 2.060 ignoring ref for Array arguments
On Monday, July 02, 2012 14:26:33 d coder wrote:
> Greetings
>
> Normally I use released beta versions of dmd, but this time I started using
> dmd 2.060 for sake of std.string.xformat.
>
> But I am facing issues. This version is ignoring "ref" when passing array
> as ref argument. Kindly see the code below. When I run this code it prints
> "Postblit called!" four time.
>
> Regards
> - Puneet
>
> //
> struct Foo {
> this(this) {
> import std.stdio;
> writeln("Postblit called!");
> }
> }
>
> void barArray(ref Foo[4] _f) { /*do nothing*/ }
>
> void main() {
> Foo [4] fooArray;
> barArray(fooArray);
> }
Then report it: http://d.puremagic.com/issues
- Jonathan M Davis
Re: Is this statement in http://dlang.org/dmd-windows.html still true?
On 07/01/2012 06:42 PM, Pierre Rouleau wrote: > Would the following rewrite of the above statement maintain the original > intent while conveying a little bit more information? > > "It is never a good idea to write into a string literal. "never a good idea" would be too permissive and welcoming. The documentation should simply say that writing into a string literal is undefined behavior (exactly like in other popular system languages like C and C++). The current documentation gets into unnecessary detail of what may happen and why under different environments. Well, yes. :) It is undefined behavior. Ali
dmd 2.060 ignoring ref for Array arguments
Greetings
Normally I use released beta versions of dmd, but this time I started using
dmd 2.060 for sake of std.string.xformat.
But I am facing issues. This version is ignoring "ref" when passing array
as ref argument. Kindly see the code below. When I run this code it prints
"Postblit called!" four time.
Regards
- Puneet
//
struct Foo {
this(this) {
import std.stdio;
writeln("Postblit called!");
}
}
void barArray(ref Foo[4] _f) { /*do nothing*/ }
void main() {
Foo [4] fooArray;
barArray(fooArray);
}
Re: Raw binary(to work without OS) in D
On 28/06/12 18:36, Jens Mueller wrote: Don Clugston wrote: On 28/06/12 17:00, Jens Mueller wrote: Andrei Alexandrescu wrote: On 6/28/12 10:07 AM, Roman D. Boiko wrote: On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote: I think just exposing them via .sig and .exp might be the way to go? sig is easy to confuse with sign .mantissa and .exp Letting the compiler define these properties is a solution. I thought Don is looking for something more general. But maybe this isn't needed here. Don't know. But using mantissa should be discouraged. I suggest calling them .significand and .exponent significand is preferred over mantissa by IEEE FP committee. I think it's fine to spell them out. There won't be much code using them anyway. Jens Yes, adding new properties would be the easiest way from a CTFE perspective; that way, they are endian-ness independent. It's a bit niche, but then again adding a special case for this in CTFE is niche as well. Maybe it would be the best approach. Sounds good then. With naming, I'm included to agree, but the funny thing is that we have X.mant_dig as the number of digits in the significand. You could add a deprecated alias to X.mant_dig and provide a new name. We should adopt IEEE's vocabulary where possible. There's an oddity, though: the type of X.significand would be dependent on the type of X (and for the non-existent quadruple float, it would be non-existent ucent type!) But this is no problem, is it? Would it include the implicit bit of an 80-bit x87 real (the silly bit)? Not sure what the silly bit is. You mean the bit that is implicitly always 1, don't you? mant_dig says 24 for a float. Means it is included when counting the bits. Then for consistency it should be included. Yes, the implicit bit. For float and double it isn't present, but it's there for 80bit x87 and 68K reals. But it would not be present for quadruple types. I'm not sure if it's always present on Itanium 80-bit reals. It's included in the 80-bit reals only for historical reasons -- it seemed like a good idea at the time. It allowed an optimisation for a long-obsolete algorithm.
Re: Raw binary(to work without OS) in D
On 28/06/12 18:37, David Nadlinger wrote: On Thursday, 28 June 2012 at 15:28:10 UTC, Don Clugston wrote: There's an oddity, though: the type of X.significand would be dependent on the type of X […] I don't think this is a problem at all – for example, the type of T.init depends on T as well… David Good point.
Excesive use of opIndex* in std.container.Array (and Ranges in general)
When I read the "D programming language" chapter on operator
overloading, I found that the fact there were operators
"opIndexAssign", "opIndexOpAssing" and "opIndexUnary" to be
nothing short of brilliant. Finally, a container of bools that
works for real!
However, if and when "opIndex" is capable of returning a
reference, isn't defining the above symbols gratuitous, error
prone, and worse, actually restrictive?
Case in point:
import std.container;
import std.stdio;
void main()
{
Array!int ai;
ai.length = 3;
++ai[0]; //Does not compile because the
implementation forgot to define opIndexUnary
ai[0] = ai[1] = 5; //Does not compile because opIndexAssign
does not return a value
++(++ai[0]); //Can't compile (even if opIndexUnary
existed)
(ai[0] += 5) += 5; //Can't compile
}
Here, there are 4 lines: The first doesn't compile simply because
we forgot to define the operator in the class. The second because
the return value of OpIndexAssign is defined as void. Finally,
the third and fourth simply can't compile, because
"opIndexOpAssing" and "opIndexUnary" can't be chained, at least
not without extra language support (and even then, you'd have to
pay for re-indexing every time).
If Array simply defined "ref T opIndex(size_t i)" (which it is
perfectly capable of doing), and didn't define anything else,
then all of the above would work. Lines 1 & 2 don't work because
of implement details, but can be fixed. 3 & 4 simply can't be
fixed.
In the case of containers that are capable of returning refs, is
there really a point to rolling out more code, just to get less?
(This, of course, does not hold for Array!bool, or any other
container that can't return refs)
