February 26, 2013
On Tue, Feb 26, 2013 at 10:38:39PM +0100, Vladimir Panteleev wrote:
> On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven Schveighoffer wrote:
> >Having a conversation about the design of the new std.process, I lamented that typesafe variadics must be the last element in the list of parameters.
> 
> Could the idea be expanded into allowing optional arguments in front of non-optional ones, when it is not ambiguous to do so?

+1.


T

-- 
What do you get if you drop a piano down a mineshaft? A flat minor.
February 26, 2013
On Tue, Feb 26, 2013 at 05:16:29PM -0500, Steven Schveighoffer wrote:
> On Tue, 26 Feb 2013 17:04:40 -0500, timotheecour <thelastmammoth@gmail.com> wrote:
> 
> >I proposed this a few weeks ago, but nobody gave feedback. This would enable it without worrying about special cases.
> >
> >http://forum.dlang.org/thread/miqtvuufvlwgfzblexxp@forum.dlang.org feature request: special optional argument (__FILE__, ...) AFTER variadic template.
> 
> I think this is a different problem, the issue I'm talking about is typesafe variadics, not variadic templates.
> 
> >Please let me know what you think!
> 
> Doesn't this work?
> 
> foo(string filename=__FILE__, T...)(T args)
[...]

It should work, except that you'll have template bloat (not as bad as putting __line__ in the compile-time arguments though!)


T

-- 
What are you when you run out of Monet? Baroque.
February 26, 2013
On Tue, 26 Feb 2013 17:29:10 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Tue, Feb 26, 2013 at 05:16:29PM -0500, Steven Schveighoffer wrote:
>> On Tue, 26 Feb 2013 17:04:40 -0500, timotheecour
>> <thelastmammoth@gmail.com> wrote:
>>
>> >I proposed this a few weeks ago, but nobody gave feedback. This
>> >would enable it without worrying about special cases.
>> >
>> >http://forum.dlang.org/thread/miqtvuufvlwgfzblexxp@forum.dlang.org
>> >feature request: special optional argument (__FILE__, ...) AFTER
>> >variadic template.
>>
>> I think this is a different problem, the issue I'm talking about is
>> typesafe variadics, not variadic templates.
>>
>> >Please let me know what you think!
>>
>> Doesn't this work?
>>
>> foo(string filename=__FILE__, T...)(T args)
> [...]
>
> It should work, except that you'll have template bloat (not as bad as
> putting __line__ in the compile-time arguments though!)

Well, not too bad.  The template can be a wrapper call, and would likely be inlined.

But the symbol bloat would suck...

-Steve
February 27, 2013
On 2/26/13 5:29 PM, H. S. Teoh wrote:
> On Tue, Feb 26, 2013 at 05:16:29PM -0500, Steven Schveighoffer wrote:
>> On Tue, 26 Feb 2013 17:04:40 -0500, timotheecour
>> <thelastmammoth@gmail.com>  wrote:
>>
>>> I proposed this a few weeks ago, but nobody gave feedback. This
>>> would enable it without worrying about special cases.
>>>
>>> http://forum.dlang.org/thread/miqtvuufvlwgfzblexxp@forum.dlang.org
>>> feature request: special optional argument (__FILE__, ...) AFTER
>>> variadic template.
>>
>> I think this is a different problem, the issue I'm talking about is
>> typesafe variadics, not variadic templates.
>>
>>> Please let me know what you think!
>>
>> Doesn't this work?
>>
>> foo(string filename=__FILE__, T...)(T args)
> [...]
>
> It should work, except that you'll have template bloat (not as bad as
> putting __line__ in the compile-time arguments though!)

Just forward immediately to a regular function. That gets rid of the bloat.

Andrei

February 27, 2013
On 2013-02-26 21:29, Steven Schveighoffer wrote:
> Having a conversation about the design of the new std.process, I
> lamented that typesafe variadics must be the last element in the list of
> parameters.
>
> But I would love to have a version that simply takes parameters as
> parameters.  In Tango's process class, it was a nice feature.  Stuff
> like this just worked:
>
> setArgs("prog.exe", "arg1", "arg2");
>
> setArgs("prog.exe arg1 arg2".split());
>
> All with one function.
>
> Because spawnProcess has optional parameters at the end, it makes it
> impossible to have this, since typesafe variadics requires that the
> variadic be the last part of the function parameters, and spawnProcess
> must take the optional stream and config parameters last.
>
> But why?  This seems perfectly plausible to me:
>
> spawnProcess(string progname, string[] args..., File _stdin = stdin,
> File _stdout = stdout, File _stderr = stderr, Config config = Config.none);
>
> There is no ambiguity with something like:
>
> spawnProcess("prog.exe", "arg1", "arg2", File("infile.txt"));
>
> A string does not implicitly convert to a File, and vice versa.
>
> Typesafe variadics are actually extremely simple to deal with (much
> simpler than C-style or D-style variadics), it's just passed as a simple
> D slice.  The compiler takes care of the nasty parts, and is entirely
> call-side.
>
> Basically, in order for this to work, a typesafe variadic parameter must
> have no way to implicitly convert to or from the type of the next
> parameters, up to the first non-variadic parameter.
>
> In other words:
>
> void foo(T[] arg1..., U[] arg2..., V arg3, W[] arg4...)
>
> This works if T, U and V cannot be implicitly converted to each other.
> W can implicitly convert to or from V, because V is positional (there
> MUST be one V argument in this call, and that matches arg3, so any args
> after that are assumed to be arg4)
>
> Would this work? Would it be something people want?
>
> -Steve

I like. But in the case of spawnProcess I would prefer named parameters:

spawnProcess("prog.exe", "arg1", "arg2", _stdin: File("infile.txt"));

-- 
/Jacob Carlborg
1 2
Next ›   Last »