February 26, 2013 Re: Typesafe variadics in any position | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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 Re: Typesafe variadics in any position | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 Re: Typesafe variadics in any position | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 Re: Typesafe variadics in any position | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 Re: Typesafe variadics in any position | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 |
Copyright © 1999-2021 by the D Language Foundation