On Tuesday, 7 August 2012 at 15:14:09 UTC, Dejan Lekic wrote:
You do not seriously expect D to copy exactly how Haskel (or
any other similar declarative langauge) treat functions? Does
it really have to be an exact copy? I am not trying to defend D
language designer(s) here, just trying to say that D should
have own style, if there is sense behind it, it does not
necessarily have to conform 100% to any paradigm.
The main reason for me to start using D 10 years ago was the
obvious PRAGMATIC design of the language. I did not start using
it because of (possible) functional orientation. Actually, I
would probably turn my back on D if I saw it promotes
declarative style more than imperative.
I think the current mix of both worlds is the best direction
for D.
I'm not arguing, but going to give my two or three cents on the
matter; I can't recall if someone already mentioned all this.
Other than 0-1 arguments being allowed to operate with or
without parentheses, functionally is there any real reason to
disallow or force it? Aside from variables being unable to use
()'s there seems to be no real difference otherwise. In some
respects that's a good thing, but you can also take a built-in
type and seamlessly replace it with functions or properties
depending on the needs; The only difference is certain options
(like .init or .min/.max) no longer are accessible.
D can be a terse language, and building up from other language's
mistakes and faults to make something newer, more robust, more
useful. So what if there might be 3 different ways to call
something, that doesn't make any one of them wrong compared to
another. One way of calling it may be simpler or better than
another, and having parentheses unnecessarily (be it property or
otherwise) seems silly.
assuming definition: string strip(string input);
string x = "something";
auto y1 = x.strip;
auto y2 = x.strip();
auto y3 = strip(x);
All do the same thing. Since strip isn't a property, more
restrictive may prevent y1 from working. But if you want to chain
commands, the ()'s just seem ugly and don't help much. So what if
it's a function?
assuming definition: string replace(string input, string from,
string to);
auto y1 = x.strip.replace("from", "to");
auto y2 = x.strip().replace("from", "to");
auto y3 = strip(x).replace("from", "to"));
auto y4 = replace(x.strip, "from", "to"));
auto y5 = replace(x.strip(), "from", "to"));
If replace was a template, perhaps:
assuming definition: string replace(string from)(string input,
string to);
auto y1 = x.strip.replace!"from"("to");
auto y2 = x.strip().replace!"from"("to");
auto y3 = strip(x.replace!"from"("to"));
auto y4 = replace!"from"(x.strip, "to"));
auto y5 = replace!"from"(x.strip(), "to"));
In the lower two cases #2 seems the ugliest since () only tells
us it's a function but we already sort of know that with the
chaining. If properties are enforced with only one calling
convention, then only #1 or #2 will work at any given time, maybe
not even y3. #1 seems the simplest to follow during chaining in
this case. #4 & #5 can be followed fairly easily, but seems more
verbose than needed.
Expressiveness is important, and if it feels most natural
writing a certain way, or easier to follow then it should be
allowed (assuming it has no impact on performance or language
structure).
I guess at this point, I'd almost suggest leaving it as it is;
Open for the programmer, but a switch to make it more strict for
say libraries, or where there's a potential for it to be a
variable in some cases and something else (static if's for types).
