Re: why does isForwardRange work like this?
On Friday, 1 August 2014 at 04:52:35 UTC, Jonathan M Davis wrote: On Thursday, 31 July 2014 at 22:21:10 UTC, Vlad Levenfeld wrote: Yes, I see the problem now. I can't think of any reason why I'd want to make save anything but a function (especially since `save` is a verb) but I guess someone out there might have a good one. It's Andrei's fault. I'm not quite sure what he was thinking. But unfortunately, we're stuck with it. So, it's just become one of D's little quirks that we have to learn and live with. Can we not at least deprecate it? And while we're at it, the same for `dup` and `idup`?
Re: why does isForwardRange work like this?
On Friday, 1 August 2014 at 11:51:55 UTC, Marc Schütz wrote: On Friday, 1 August 2014 at 04:52:35 UTC, Jonathan M Davis wrote: On Thursday, 31 July 2014 at 22:21:10 UTC, Vlad Levenfeld wrote: Yes, I see the problem now. I can't think of any reason why I'd want to make save anything but a function (especially since `save` is a verb) but I guess someone out there might have a good one. It's Andrei's fault. I'm not quite sure what he was thinking. But unfortunately, we're stuck with it. So, it's just become one of D's little quirks that we have to learn and live with. Can we not at least deprecate it? And while we're at it, the same for `dup` and `idup`? It would break too much code to change save at this point. There's no way that you're going to talk Andrei or Walter into changing something like that over whether it makes sense for it to be a property or not. That's not the kind of thing that they think is important, and you're more likely to get Andrei to try and kill of @property again rather than anything useful. As for dup and idup, they were replaced with functions recently (maybe for 2.066 but not 2.065 - i'm not sure when the changes were made), so they might actually work with parens now. I'm not sure. But since dup and idup aren't being implemented by lots of different people like the range API is, changing those doesn't risk breaking code where folks made it a variable. - Jonathan M Davis
Re: why does isForwardRange work like this?
On Friday, 1 August 2014 at 19:59:16 UTC, Jonathan M Davis wrote: But since dup and idup aren't being implemented by lots of different people like the range API is, changing those doesn't risk breaking code where folks made it a variable. Well, I probably shouldn't put it quite that way, since that's not the only problem with changing save (which I guess that that statement implies). The real problem with changing save is that we'd have to change the template constraint to use save() to make sure that no one declared it as a variable, and that would break everyone's code who declared save as a property - so, everyone. And _that_ is why save isn't going to change. - Jonathan M Davis
Re: why does isForwardRange work like this?
On Thursday, 31 July 2014 at 20:34:42 UTC, Vlad Levenfeld wrote: What's the rationale behind stating the condition this way as opposed to, say, is (typeof(R.init.save)) == R) || is ((typeof(R.init.save()) == R) so that member fields as well as @property and non-@property methods will match save should never have been a property, since it doesn't really emulate a variable, but because it was decided that it was a property, it is required by the API that it be a property. And the reason why it's required to be a property once it was decided that it should be one is quite simple. What would happen if you a function did this auto s = range.save(); and save was a property? The code would fail to compile. Because it was decided that save should be a property, _every_ time that save is used, it must be used as a property, or it won't work with any range that did define save as a property. As such, there is no reason to allow save to be a non-property function. Allowing that would just make it easier to write code which called save incorrectly but worked with the ranges that it was tested with (because they defined save as a function instead of a property). In addition, if it works with your range, it's perfectly legal to define save as a member variable (though that would be a rather bizarre thing to do), and allowing save to be called as a function by the range API would break that. So, once it's been decided that it's legal for something in a templated API to be a property, it _must_ be a property, a variable, or an enum, or there are going to be problems, because it has to be used without parens. - Jonathan M Davis
Re: why does isForwardRange work like this?
Yes, I see the problem now. I can't think of any reason why I'd want to make save anything but a function (especially since `save` is a verb) but I guess someone out there might have a good one. So, what is gained by (inout int = 0) over ()? I wasn't even aware that giving a default value for an unlabeled parameter would compile. What does it do?
Re: why does isForwardRange work like this?
On Thursday, 31 July 2014 at 22:21:10 UTC, Vlad Levenfeld wrote: Yes, I see the problem now. I can't think of any reason why I'd want to make save anything but a function (especially since `save` is a verb) but I guess someone out there might have a good one. It's Andrei's fault. I'm not quite sure what he was thinking. But unfortunately, we're stuck with it. So, it's just become one of D's little quirks that we have to learn and live with. So, what is gained by (inout int = 0) over ()? I wasn't even aware that giving a default value for an unlabeled parameter would compile. What does it do? I've wondered that myself but never taken the time to look into it. However, according to this post: http://forum.dlang.org/post/mailman.102.1396007039.25518.digitalmars-d-le...@puremagic.com it looks like it convinces the compiler to make the function an inout function so that the range variable that's declared can be treated as inout and therefore be able to have ranges with inout in their type work.
Re: Why does this work?
h_zet: Problem solved, Thank you so much! I don't think it's solved. There are probably bugs worth reporting here. Bye, bearophile
Re: Why does this work?
I don't think it's solved. There are probably bugs worth reporting here. I have not found them, sorry for the noise. Bye, bearophile
Re: Why does this work?
On Tuesday, 24 June 2014 at 10:11:05 UTC, bearophile wrote: I don't think it's solved. There are probably bugs worth reporting here. I have not found them, sorry for the noise. Bye, bearophile This looks really bad. I thought we weren't going to allow variable templates, just enums and aliases?
Re: Why does this work?
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
Looks grammaticallyu correct: R type is guessed/infered from the
parameter
Re: Why does this work?
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
You declared a variable template named tuple (with unused type
parameters a, b) on that line.
http://dlang.org/template.html#variable-template
I think this is very confusable syntax...
void main()
{
auto tuple(a, b) = foo2(1);
writeln(tuple!(int, int)); // writes Tuple!(int, bool)(1,
true)
tuple!(int, int) = foo2(20);
writeln(tuple!(int, int)); // writes Tuple!(int, bool)(20,
true)
}
Re: Why does this work?
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
Strange behavior, indeed. It took me a minute, but I think I know
what's going on, and I'm pretty sure it's a bug. D recently
introduced a short syntax for function-like templates:
enum a(b) = some_value;
It looks like this also (sort of) works with other qualifiers,
which I believe it shouldn't. Here's a minimal example that might
be good to put in a bug report:
void main() {
enum a(x) = some_value; // Good.
auto b(x) = some_value; // Huh?
// This also works for `const`, `static`, etc.
}
Re: Why does this work?
On Monday, 23 June 2014 at 09:29:15 UTC, Mason McGill wrote:
Strange behavior, indeed. It took me a minute, but I think I
know what's going on, and I'm pretty sure it's a bug. D
recently introduced a short syntax for function-like templates:
enum a(b) = some_value;
It looks like this also (sort of) works with other qualifiers,
which I believe it shouldn't. Here's a minimal example that
might be good to put in a bug report:
void main() {
enum a(x) = some_value; // Good.
auto b(x) = some_value; // Huh?
// This also works for `const`, `static`, etc.
}
It looks like I'm mistaken. Variable templates are supposed to
exist. Please ignore the previous post.
Re: Why does this work?
h_zet: Why does this work? Or it is a bug? When you play a little with this code it's easy to see _error_ that should not appear. So there's surely something worth reporting as bug, but I don't yet know what. Bye, bearophile
Re: Why does this work?
On Monday, 23 June 2014 at 09:09:56 UTC, hane wrote:
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
You declared a variable template named tuple (with unused
type parameters a, b) on that line.
http://dlang.org/template.html#variable-template
I think this is very confusable syntax...
void main()
{
auto tuple(a, b) = foo2(1);
writeln(tuple!(int, int)); // writes Tuple!(int, bool)(1,
true)
tuple!(int, int) = foo2(20);
writeln(tuple!(int, int)); // writes Tuple!(int, bool)(20,
true)
}
Problem solved, Thank you so much!
Re: Why does this work?
Mike L. Wrote: I saved and compiled the code given as getenv.d on the page http://www.digitalmars.com/d/archives/digitalmars/D/learn/623.html but I'm not entirely sure why it works. The reasons that I don't understand it are: 1. GetEnvironmentStringsA() and the other functions aren't mentioned in std/c/windows/windows.d . It is not defined int std.c.windows.windows, that's why it is defined in the code itself: # // function retrieves the environment variables for the current process. # extern( Windows ) LPVOID GetEnvironmentStringsA(); # and I can compile it with a simple dmd getenv.d without passing any other object files or libraries. If it's not in windows.d, why is windows.d even imported? std.c.windows.windows is imported so that compiler knows about LPSTR, LPVOID, BOOL etc. 2. MSDN says that GetEnvironmentStringsA() returns LPTCH but getenv.d's version returns LPVOID. That's true, you should update function's return type and remove unneccessary casts: extern( Windows ) LPTSTR GetEnvironmentStringsA(); ... for (lpszVariable = lpvEnv; *lpszVariable; lpszVariable++)
Re: Why does this work?
Denis Koroskin Wrote: Mike L. Wrote: I saved and compiled the code given as getenv.d on the page http://www.digitalmars.com/d/archives/digitalmars/D/learn/623.html but I'm not entirely sure why it works. The reasons that I don't understand it are: 1. GetEnvironmentStringsA() and the other functions aren't mentioned in std/c/windows/windows.d . It is not defined int std.c.windows.windows, that's why it is defined in the code itself: # // function retrieves the environment variables for the current process. # extern( Windows ) LPVOID GetEnvironmentStringsA(); # and I can compile it with a simple dmd getenv.d without passing any other object files or libraries. If it's not in windows.d, why is windows.d even imported? std.c.windows.windows is imported so that compiler knows about LPSTR, LPVOID, BOOL etc. 2. MSDN says that GetEnvironmentStringsA() returns LPTCH but getenv.d's version returns LPVOID. That's true, you should update function's return type and remove unneccessary casts: extern( Windows ) LPTSTR GetEnvironmentStringsA(); ... for (lpszVariable = lpvEnv; *lpszVariable; lpszVariable++) Thanks for your response. Could you tell me what the compiler is linking to that contains GetEnvironmentStringsA() (and others) and how the compiler knows to do this?
