Thread overview
Re: why doesn't formattedRead take args by ref instead of by pointer?
May 20, 2013
Timothee Cour
May 20, 2013
Ali Çehreli
May 20, 2013
Dmitry Olshansky
May 20, 2013
Timothee Cour
May 20, 2013
Dmitry Olshansky
May 20, 2013
Timothee Cour
May 21, 2013
Dmitry Olshansky
Aug 17, 2013
Timothee Cour
Aug 17, 2013
Dmitry Olshansky
May 20, 2013
ping on this.
Also, same question with std.getopt, which takes by pointer instead of by
ref.


On Thu, May 16, 2013 at 12:54 AM, Timothee Cour <thelastmammoth@gmail.com>wrote:

>
> If I change formattedRead's input signature to:
> uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, ref S args)
> and adjusted code accordingly.
>
> It seems to work fine.
>
> see implementation here:
>
> https://github.com/timotheecour/dtools/blob/master/dtools/overrides/format.d#L29 (just run unittests: rdmd --main -unittest dtools/all.d)
>
> why is std.format. formattedRead taking by pointer instead ?
> could we change that (with proper deprecation), or add that function?
>
>


May 20, 2013
On 05/20/2013 01:55 PM, Timothee Cour wrote:

>> why is std.format. formattedRead taking by pointer instead ?
>> could we change that (with proper deprecation), or add that function?

It must be simply historical. readf takes pointers as well.

Ali

May 20, 2013
21-May-2013 00:55, Timothee Cour пишет:
> ping on this.
> Also, same question with std.getopt, which takes by pointer instead of
> by ref.
>

IRC there was a problem with having a heterogeneous variadic (=compiler's type tuple) function to preserve ref-ness.
>
> On Thu, May 16, 2013 at 12:54 AM, Timothee Cour
> <thelastmammoth@gmail.com <mailto:thelastmammoth@gmail.com>> wrote:
>
>
>     If I change formattedRead's input signature to:
>     uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, ref S
>     args)
>     and adjusted code accordingly.
>
>     It seems to work fine.
>
>     see implementation here:
>     https://github.com/timotheecour/dtools/blob/master/dtools/overrides/format.d#L29
>     (just run unittests: rdmd --main -unittest dtools/all.d)
>
>     why is std.format. formattedRead taking by pointer instead ?
>     could we change that (with proper deprecation), or add that function?
>
>


-- 
Dmitry Olshansky
May 20, 2013
> IRC there was a problem with having a heterogeneous variadic (=compiler's type tuple) function to preserve ref-ness.


could you please provide a code snippet demonstrating this?


May 20, 2013
21-May-2013 01:19, Timothee Cour пишет:
>
>     IRC there was a problem with having a heterogeneous variadic
>     (=compiler's type tuple) function to preserve ref-ness.
>
>
> could you please provide a code snippet demonstrating this?
>
>

Here:

void readf(Args...)(const(char)[] fmt, Args args)
{
...
}

the problem was that you couldn't do

void readf(Args...)(const(char)[] fmt, ref Args args)
{
...
}

and have each of args be a 'ref' to original var as there is no such things outside function arguments declaration. I dunno how it was solved but this now works:

void readf(Args...)(const(char)[] fmt, ref Args args)
{
    foreach(i, v; args)
        args[i] = i;
}

void main(){
    int i, j, k;
    readf("abc", i, j, k);
    assert(i == 0);
    assert(j == 1);
    assert(k == 2);
}

-- 
Dmitry Olshansky
May 20, 2013
That was indeed what I was using in my updated ref based reimplementation of formattedRead (see my original post for the link), and the other functions getopt, readf) are the same AFAIK.

so why not add it to phobos:
it's safer (no null / invalid pointers)
simpler user code
more consistent with rest of phobos

we could either make the existing by pointer functions enter a deprecation path, or add a 'formattedReadRef' version for all those functions.

Thoughts?




On Mon, May 20, 2013 at 2:28 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote:

> 21-May-2013 01:19, Timothee Cour пишет:
>
>>
>>     IRC there was a problem with having a heterogeneous variadic
>>     (=compiler's type tuple) function to preserve ref-ness.
>>
>>
>> could you please provide a code snippet demonstrating this?
>>
>>
>>
> Here:
>
> void readf(Args...)(const(char)[] fmt, Args args)
> {
> ...
> }
>
> the problem was that you couldn't do
>
> void readf(Args...)(const(char)[] fmt, ref Args args)
> {
> ...
> }
>
> and have each of args be a 'ref' to original var as there is no such things outside function arguments declaration. I dunno how it was solved but this now works:
>
> void readf(Args...)(const(char)[] fmt, ref Args args)
> {
>     foreach(i, v; args)
>         args[i] = i;
> }
>
> void main(){
>     int i, j, k;
>     readf("abc", i, j, k);
>     assert(i == 0);
>     assert(j == 1);
>     assert(k == 2);
> }
>
> --
> Dmitry Olshansky
>


May 21, 2013
21-May-2013 01:39, Timothee Cour пишет:
> That was indeed what I was using in my updated ref based
> reimplementation of formattedRead (see my original post for the link),
> and the other functions getopt, readf) are the same AFAIK.
>
> so why not add it to phobos:
> it's safer (no null / invalid pointers)
> simpler user code
> more consistent with rest of phobos
>
> we could either make the existing by pointer functions enter a
> deprecation path, or add a 'formattedReadRef' version for all those
> functions.
>
> Thoughts?

You can just add an overload I bet. Since you can't read a pointer and &x is an r-value and (thank god) there wasn't decision to allow r-value as plain ref.


-- 
Dmitry Olshansky
August 17, 2013
adding an overload would increases likelihood for bugs but could be possible. The same holds for getopt.

Another question:
the documentation for formattedRead is quite sparse, how does it explain
the following behavior:

  string s="a1 a2 a3";
  string a,b;
  uint n=formattedRead(s,"%s %s",&a,&b);
  assert(a=="a1" && b=="a2 a3");



On Mon, May 20, 2013 at 10:44 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote:

> 21-May-2013 01:39, Timothee Cour пишет:
>
>  That was indeed what I was using in my updated ref based
>> reimplementation of formattedRead (see my original post for the link),
>> and the other functions getopt, readf) are the same AFAIK.
>>
>> so why not add it to phobos:
>> it's safer (no null / invalid pointers)
>> simpler user code
>> more consistent with rest of phobos
>>
>> we could either make the existing by pointer functions enter a deprecation path, or add a 'formattedReadRef' version for all those functions.
>>
>> Thoughts?
>>
>
> You can just add an overload I bet. Since you can't read a pointer and &x is an r-value and (thank god) there wasn't decision to allow r-value as plain ref.
>
>
> --
> Dmitry Olshansky
>


August 17, 2013
17-Aug-2013 12:53, Timothee Cour пишет:
> adding an overload would increases likelihood for bugs but could be
> possible. The same holds for getopt.
>
> Another question:
> the documentation for formattedRead is quite sparse, how does it explain
> the following behavior:
>
>    string s="a1 a2 a3";
>    string a,b;
>    uint n=formattedRead(s,"%s %s",&a,&b);
>    assert(a=="a1" && b=="a2 a3");
>

Seems like "a1_a2 a3" with _ being matched as space in format string between %s and %s.
Why %s is not stopping on any whitespace as is (like scanf) I'm not 100% sure.

>
>
> On Mon, May 20, 2013 at 10:44 PM, Dmitry Olshansky
> <dmitry.olsh@gmail.com <mailto:dmitry.olsh@gmail.com>> wrote:
>
>     21-May-2013 01:39, Timothee Cour пишет:
>
>         That was indeed what I was using in my updated ref based
>         reimplementation of formattedRead (see my original post for the
>         link),
>         and the other functions getopt, readf) are the same AFAIK.
>
>         so why not add it to phobos:
>         it's safer (no null / invalid pointers)
>         simpler user code
>         more consistent with rest of phobos
>
>         we could either make the existing by pointer functions enter a
>         deprecation path, or add a 'formattedReadRef' version for all those
>         functions.
>
>         Thoughts?
>
>
>     You can just add an overload I bet. Since you can't read a pointer
>     and &x is an r-value and (thank god) there wasn't decision to allow
>     r-value as plain ref.
>
>
>     --
>     Dmitry Olshansky
>
>


-- 
Dmitry Olshansky