• Chad J (9/9) Aug 01 2009 Omissible Parentheses
• Denis Koroskin (3/12) Aug 01 2009 Andrei likes them.
• Michel Fortin (8/25) Aug 01 2009 I like them too, despite their gotchas. If they were not cause for
• Andrei Alexandrescu (4/21) Aug 01 2009 http://igsoft.net/dpolls/poll/results.php?pollid=1
• Benji Smith (5/29) Aug 01 2009 If I'm not mistaken, each of those polls shows a two-to-one preference
• Adam D. Ruppe (15/26) Aug 01 2009 They also prove that there are more than one person who are fairly happy
• Robert Jacques (4/19) Aug 01 2009 I like them too (a lot). I find they increase the clarity of my code
• Michiel Helvensteijn (6/8) Aug 01 2009 I think that when you find you need to use function-chaining, the functi...
• Robert Jacques (7/14) Aug 01 2009 Nope. I meant _function_ chaining. This comment comes mostly from using ...
• Chad J (3/23) Aug 02 2009 Interesting. I don't think I've seen this angle yet.
• KennyTM~ (2/25) Aug 02 2009 "

  yes?

  ".replace("<", "<").replace(">", ">");
• Michiel Helvensteijn (6/11) Aug 02 2009 Sure, but they have parameters, so they require parentheses anyway. Robe...
• Leandro Lucarella (17/28) Aug 02 2009 Well, just take parameter-less functions then:
• Michiel Helvensteijn (5/8) Aug 02 2009 Those would be fine candidates for read-only properties:
• Leandro Lucarella (10/19) Aug 02 2009 That looks a little better indeed =)
• Robert Jacques (8/31) Aug 02 2009 I think its better to prioritize readability too, it's just that to me
• Chad J (5/32) Aug 02 2009 I'm not seeing the use of function/property duals or the lack of
• Denis Koroskin (3/39) Aug 02 2009 Stdout("Hello, World!").newline.newline.newline;
• Chad J (2/33) Aug 02 2009 Thanks
• Michel Fortin (9/10) Aug 02 2009 This syntax/wording just looks wrong to me. "newline" isn't a verb,
• Benji Smith (8/9) Aug 03 2009 Ugh. This is one of the few things about Tango that really drives me
• Jarrett Billingsley (5/11) Aug 03 2009 For what it's worth, "all" the use of opCall overloads is pretty much
• Ary Borenszweig (22/32) Aug 04 2009 Another thing about omissable parenthesis and function calls. When you
• Ary Borenszweig (2/18) Aug 04 2009 Oops, typo: should *not* imply a function call.
• Robert Jacques (10/34) Aug 02 2009 Here are two examples from a couple of days ago:
• Chad J (2/31) Aug 02 2009 Thank you.
• Andrei Alexandrescu (4/37) Aug 02 2009 BTW now Phobos has

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Omissible Parentheses

Could someone remind me why we don't remove these?

So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- They allow some features of properties, but with a list of limitations
and gotchas.

This is not intended to be a deep discussion.  I'm writing a piece on
properties, so I'm gathering information.

"Denis Koroskin" <2korden gmail.com> writes:

On Sat, 01 Aug 2009 21:04:43 +0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.

Andrei likes them.

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-08-01 13:05:26 -0400, "Denis Koroskin" <2korden gmail.com> said:

 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J  
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Omissible Parentheses
 
 Could someone remind me why we don't remove these?
 
 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.
 
 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.

 
 Andrei likes them.

I like them too, despite their gotchas. If they were not cause for 
special rules when returning delegates, also classes and structs with 
an opCall member, I'd want to keep them.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Denis Koroskin wrote:
 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J 
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.

 
 Andrei likes them.

http://igsoft.net/dpolls/poll/results.php?pollid=1
http://igsoft.net/dpolls/poll/results.php?pollid=2


Andrei

Benji Smith <dlanguage benjismith.net> writes:

Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J 
 <chadjoan __spam.is.bad__gmail.com> wrote:

 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.

 Andrei likes them.

 
 http://igsoft.net/dpolls/poll/results.php?pollid=1
 http://igsoft.net/dpolls/poll/results.php?pollid=2
 
 
 Andrei

If I'm not mistaken, each of those polls shows a two-to-one preference 
for getting rid of omissable parentheses and introducing a dedicated 
property syntax of some kind.

--benji

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Sat, Aug 01, 2009 at 11:49:04PM -0400, Benji Smith wrote:
http://igsoft.net/dpolls/poll/results.php?pollid=1
http://igsoft.net/dpolls/poll/results.php?pollid=2


Andrei

 
 If I'm not mistaken, each of those polls shows a two-to-one preference 
 for getting rid of omissable parentheses and introducing a dedicated 
 property syntax of some kind.

They also prove that there are more than one person who are fairly happy
with the current system.

There might be a majority in favor of a change, but the prospects are much
more iffy about there being enough votes to kill our filibuster!


(I'm not sure if filibusters are common outside of American politics, so
 if you aren't familiar with the term, it is when someone in the US Senate
 debates a proposed bill non stop until the proposal just dies and nothing
 is changed. The filibuster can be stopped with 60 votes out of the 100
 senators - something that can be a pain to get, and leads to a lot of 
 compromise to keep the bill alive.

 In other words: see what happens on this newsgroup :P )


 
 --benji

-- 
Adam D. Ruppe
http://arsdnet.net

"Robert Jacques" <sandford jhu.edu> writes:

On Sat, 01 Aug 2009 13:05:26 -0400, Denis Koroskin <2korden gmail.com>  
wrote:

 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J  
 <chadjoan __spam.is.bad__gmail.com> wrote:

 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.

 Andrei likes them.

I like them too (a lot). I find they increase the clarity of my code  
(particularly function chaining).

Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:

Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

I think that when you find you need to use function-chaining, the functions
(except possibly the rightmost) are often meant to be properties/fields.
That's why they would look more natural without parentheses.

-- 
Michiel Helvensteijn

"Robert Jacques" <sandford jhu.edu> writes:

On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn  
<m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

 I think that when you find you need to use function-chaining, the  
 functions
 (except possibly the rightmost) are often meant to be properties/fields.
 That's why they would look more natural without parentheses.

Nope. I meant _function_ chaining. This comment comes mostly from using  
std.string and std.algorithm, whose functions don't behave as fields. Both  
of these libraries show off the power you get from the flexibility of  
function call / property duality. I've also used toggle/flag setting  
methods in this way. It's concise, clean and very understandable.

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:
 
 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

 I think that when you find you need to use function-chaining, the
 functions
 (except possibly the rightmost) are often meant to be properties/fields.
 That's why they would look more natural without parentheses.

 
 Nope. I meant _function_ chaining. This comment comes mostly from using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the flexibility
 of function call / property duality. I've also used toggle/flag setting
 methods in this way. It's concise, clean and very understandable.
 

Interesting.  I don't think I've seen this angle yet.

Could you provide code examples, please?

KennyTM~ <kennytm gmail.com> writes:

Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

 I think that when you find you need to use function-chaining, the
 functions
 (except possibly the rightmost) are often meant to be properties/fields.
 That's why they would look more natural without parentheses.

 Nope. I meant _function_ chaining. This comment comes mostly from using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the flexibility
 of function call / property duality. I've also used toggle/flag setting
 methods in this way. It's concise, clean and very understandable.

 
 Interesting.  I don't think I've seen this angle yet.
 
 Could you provide code examples, please?

"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");

Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:

KennyTM~ wrote:

 Interesting.  I don't think I've seen this angle yet.
 
 Could you provide code examples, please?

 
 "<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");

Sure, but they have parameters, so they require parentheses anyway. Robert
Jacques was talking about omissible parentheses for function chaining. That
would require parameter-less functions.

-- 
Michiel Helvensteijn

Leandro Lucarella <llucax gmail.com> writes:

Michiel Helvensteijn, el  2 de agosto a las 16:25 me escribiste:
 KennyTM~ wrote:
 
 Interesting.  I don't think I've seen this angle yet.
 
 Could you provide code examples, please?

 
 "<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");

 
 Sure, but they have parameters, so they require parentheses anyway. Robert
 Jacques was talking about omissible parentheses for function chaining. That
 would require parameter-less functions.

Well, just take parameter-less functions then:

" hello   ".strip.toupper.replace("O", "A"); // "HELLA"

(I don't know if that even compiles in D2)

I think it's better to have mandatory (), though. Even when you save
a couple of strokes there, I find that code way more confusing than the
same with () (from that code it looks like hello has a strip property
which in case have a toupper property which then have a replace method).

Again, is a tradeoff between writeability and readability. I think is way
more important to prioritize readability.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
- i bet microsoft's developers were on diet when they had to do win95
- microsoft has developers?

Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:

Leandro Lucarella wrote:

 Well, just take parameter-less functions then:
 
 " hello   ".strip.toupper.replace("O", "A"); // "HELLA"

Those would be fine candidates for read-only properties:

" hello   ".stripped.inupper.replace("O", "A");

-- 
Michiel Helvensteijn

Leandro Lucarella <llucax gmail.com> writes:

Michiel Helvensteijn, el  2 de agosto a las 20:08 me escribiste:
 Leandro Lucarella wrote:
 
 Well, just take parameter-less functions then:
 
 " hello   ".strip.toupper.replace("O", "A"); // "HELLA"

 
 Those would be fine candidates for read-only properties:
 
 " hello   ".stripped.inupper.replace("O", "A");

That looks a little better indeed =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
You look so tired-unhappy,
bring down the government,
they don't, they don't speak for us.

"Robert Jacques" <sandford jhu.edu> writes:

On Sun, 02 Aug 2009 14:02:37 -0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Michiel Helvensteijn, el  2 de agosto a las 16:25 me escribiste:
 KennyTM~ wrote:

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?

 "<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");

 Sure, but they have parameters, so they require parentheses anyway.  
 Robert
 Jacques was talking about omissible parentheses for function chaining.  
 That
 would require parameter-less functions.

 Well, just take parameter-less functions then:

 " hello   ".strip.toupper.replace("O", "A"); // "HELLA"

 (I don't know if that even compiles in D2)

 I think it's better to have mandatory (), though. Even when you save
 a couple of strokes there, I find that code way more confusing than the
 same with () (from that code it looks like hello has a strip property
 which in case have a toupper property which then have a replace method).

 Again, is a tradeoff between writeability and readability. I think is way
 more important to prioritize readability.

I think its better to prioritize readability too, it's just that to me  
"hello".strip.toupper; is more readable than "hello".strip().toupper();.  
I've long since ceased to use () on zero argument functions and have never  
looked back.

BTW, I think you meant a strip field, since a property is just a method  
call with some syntactic sugar.

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

KennyTM~ wrote:
 Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

 I think that when you find you need to use function-chaining, the
 functions
 (except possibly the rightmost) are often meant to be
 properties/fields.
 That's why they would look more natural without parentheses.

 Nope. I meant _function_ chaining. This comment comes mostly from using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the flexibility
 of function call / property duality. I've also used toggle/flag setting
 methods in this way. It's concise, clean and very understandable.

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?

 
 "<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");

I'm not seeing the use of function/property duals or the lack of
parentheses.  Am I missing it?

(To be clear, I am not looking for an example of function chaining.  I'd
like to see why function/property duals are useful for function chaining.)

"Denis Koroskin" <2korden gmail.com> writes:

On Sun, 02 Aug 2009 18:30:33 +0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 KennyTM~ wrote:
 Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

 I think that when you find you need to use function-chaining, the
 functions
 (except possibly the rightmost) are often meant to be
 properties/fields.
 That's why they would look more natural without parentheses.

 Nope. I meant _function_ chaining. This comment comes mostly from  
 using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the  
 flexibility
 of function call / property duality. I've also used toggle/flag  
 setting
 methods in this way. It's concise, clean and very understandable.

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?

 "<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");

 I'm not seeing the use of function/property duals or the lack of
 parentheses.  Am I missing it?

 (To be clear, I am not looking for an example of function chaining.  I'd
 like to see why function/property duals are useful for function  
 chaining.)

Stdout("Hello, World!").newline.newline.newline;

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Denis Koroskin wrote:
 On Sun, 02 Aug 2009 18:30:33 +0400, Chad J
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 KennyTM~ wrote:
 Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 Nope. I meant _function_ chaining. This comment comes mostly from
 using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the
 flexibility
 of function call / property duality. I've also used toggle/flag
 setting
 methods in this way. It's concise, clean and very understandable.

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?

 "<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");

 I'm not seeing the use of function/property duals or the lack of
 parentheses.  Am I missing it?

 (To be clear, I am not looking for an example of function chaining.  I'd
 like to see why function/property duals are useful for function
 chaining.)

 
 Stdout("Hello, World!").newline.newline.newline;

Thanks

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-08-02 11:01:01 -0400, "Denis Koroskin" <2korden gmail.com> said:

 Stdout("Hello, World!").newline.newline.newline;

This syntax/wording just looks wrong to me. "newline" isn't a verb, 
it's more like a noun and thus should be a property, a getter in this 
case. But it does an action and return the stream, it's no getter at 
all. Completly backward.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Benji Smith <dlanguage benjismith.net> writes:

Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;

Ugh. This is one of the few things about Tango that really drives me 
nuts. I hate all the usage of the opCall overload and non-parenthetized 
function calls.

At first glance, that code doesn't make any sense to me. My brain just 
doesn't grok what's going on. It takes me a split second to mentally 
parse it.

--benji

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Aug 3, 2009 at 9:26 PM, Benji Smith<dlanguage benjismith.net> wrote:
 Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;

 Ugh. This is one of the few things about Tango that really drives me nuts. I
 hate all the usage of the opCall overload and non-parenthetized function
 calls.

For what it's worth, "all" the use of opCall overloads is pretty much
exclusively limited to Stdout (or more generally,
tango.io.stream.Format).  And the omission of parens everywhere is
just Kris' style.  I can't read half his code because of it :P

Ary Borenszweig <ary esperanto.org.ar> writes:

Benji Smith wrote:
 Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;

 
 Ugh. This is one of the few things about Tango that really drives me 
 nuts. I hate all the usage of the opCall overload and non-parenthetized 
 function calls.
 
 At first glance, that code doesn't make any sense to me. My brain just 
 doesn't grok what's going on. It takes me a split second to mentally 
 parse it.

Another thing about omissable parenthesis and function calls. When you 
define an opCall, to use it you must write "()". That implies that to 
call a function you must write "()". So not writing "()" should imply a 
function call!

--
import std.stdio;

struct Bar {
     Foo foo;
}

struct Foo {
     int opCall() {
         return 1;
     }
}

void main() {
     Bar bar;
     writefln("%s", bar.foo); // prints Foo
     writefln("%s", bar.foo()); // prints 1
}
--

Isn't that an inconsistency?

Ary Borenszweig <ary esperanto.org.ar> writes:

Ary Borenszweig wrote:
 Benji Smith wrote:
 Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;

 Ugh. This is one of the few things about Tango that really drives me 
 nuts. I hate all the usage of the opCall overload and 
 non-parenthetized function calls.

 At first glance, that code doesn't make any sense to me. My brain just 
 doesn't grok what's going on. It takes me a split second to mentally 
 parse it.

 
 Another thing about omissable parenthesis and function calls. When you 
 define an opCall, to use it you must write "()". That implies that to 
 call a function you must write "()". So not writing "()" should imply a 
 function call!

Oops, typo: should *not* imply a function call.

"Robert Jacques" <sandford jhu.edu> writes:

On Sun, 02 Aug 2009 09:06:29 -0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

 I think that when you find you need to use function-chaining, the
 functions
 (except possibly the rightmost) are often meant to be  
 properties/fields.
 That's why they would look more natural without parentheses.

 Nope. I meant _function_ chaining. This comment comes mostly from using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the flexibility
 of function call / property duality. I've also used toggle/flag setting
 methods in this way. It's concise, clean and very understandable.

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?

Here are two examples from a couple of days ago:

auto data = (cast(string)std.file.read(filename)).chomp.split;

set_colour.uses = (new Texture!float4(mod,"TRANSFER",  
tranfer_data)).normalize.clamp.linear;

I'd also point out 'uses' is overloaded with a variadic version:

CCK_engine.uses( iCCK, a_p, a_p2, a_t);

There were also a bunch of std.algorithm examples in the newsgroup back  
with the new phobos was launched. (Though this only works for arrays)

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Robert Jacques wrote:
 On Sun, 02 Aug 2009 09:06:29 -0400, Chad J
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Robert Jacques wrote:
 Nope. I meant _function_ chaining. This comment comes mostly from using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the flexibility
 of function call / property duality. I've also used toggle/flag setting
 methods in this way. It's concise, clean and very understandable.

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?

 
 Here are two examples from a couple of days ago:
 
 auto data = (cast(string)std.file.read(filename)).chomp.split;
 
 set_colour.uses = (new Texture!float4(mod,"TRANSFER",
 tranfer_data)).normalize.clamp.linear;
 
 I'd also point out 'uses' is overloaded with a variadic version:
 
 CCK_engine.uses( iCCK, a_p, a_p2, a_t);
 
 There were also a bunch of std.algorithm examples in the newsgroup back
 with the new phobos was launched. (Though this only works for arrays)

Thank you.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Robert Jacques wrote:
 On Sun, 02 Aug 2009 09:06:29 -0400, Chad J 
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).

 I think that when you find you need to use function-chaining, the
 functions
 (except possibly the rightmost) are often meant to be 
 properties/fields.
 That's why they would look more natural without parentheses.

 Nope. I meant _function_ chaining. This comment comes mostly from using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the flexibility
 of function call / property duality. I've also used toggle/flag setting
 methods in this way. It's concise, clean and very understandable.

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?

 
 Here are two examples from a couple of days ago:
 
 auto data = (cast(string)std.file.read(filename)).chomp.split;

BTW now Phobos has

auto data = std.file.readText(filename).chomp.split;


Andrei