On Thu, 08 Sep 2011 16:19:28 -0400, Christophe
wrote:
"Steven Schveighoffer" , dans le message (digitalmars.D:144156), a
écrit :
Where could I see an
implementation of a delegate suitable for readUntil ?
In the source code for the revamped stdio. Here is a byChunk range
which
uses it:
"Steven Schveighoffer" , dans le message (digitalmars.D:144156), a
écrit :
>> Where could I see an
>> implementation of a delegate suitable for readUntil ?
>
> In the source code for the revamped stdio. Here is a byChunk range which
> uses it:
I see. Are you not concerned by the fact that wit
On Tue, 06 Sep 2011 19:46:35 -0400, Christophe
wrote:
I've had a look at readUntil API, and it's not completely clear. Is the
delegate supposed to remember what it has read and interpreted so far,
or does it have to start from scratch each time ?
The start is an index at which new data was
On 2011-09-06 18:15, Marco Leise wrote:
Ok I get the picture, but the details are vague.
- How are pointers printed? As a hex value or as the data they point to
(flat toString vs. deep toString). A serialization API typically follows
class references and pointers.
If the pointer points to a va
I've had a look at readUntil API, and it's not completely clear. Is the
delegate supposed to remember what it has read and interpreted so far,
or does it have to start from scratch each time ? Where could I see an
implementation of a delegate suitable for readUntil ?
Basically, in both your and
Am 06.09.2011, 11:12 Uhr, schrieb Jacob Carlborg :
On 2011-09-05 20:37, Marco Leise wrote:
Am 05.09.2011, 19:51 Uhr, schrieb Sean Kelly :
Right. Which is why I've suggested in the past that we may want to use
the serialization calls for toString.
I'm highly skeptical to say the least :). I k
On Tue, 06 Sep 2011 10:07:23 -0400, Christophe
wrote:
"Steven Schveighoffer" , dans le message (digitalmars.D:143998), a
écrit :
void readFrom(const(char)[] delegate(size_t) stream,
in char[] format = null);
-format is the usual format specifier.
-stream is a delegate that ta
Andrei Alexandrescu , dans le message (digitalmars.D:144012), a écrit :
> On 9/6/11 7:18 AM, Christophe wrote:
>>
>>> size_t readFrom(const(char)[] data, size_t start); // same as
>>> readUntil delegate
>>
>> What happens if the buffer data get exhausted ? The function calling
>> readFrom has no wa
On 9/6/11 7:18 AM, Christophe wrote:
size_t readFrom(const(char)[] data, size_t start); // same as
readUntil delegate
What happens if the buffer data get exhausted ? The function calling
readFrom has no way to know how many characters to put into data to
allow the read.
What is the point of s
"Steven Schveighoffer" , dans le message (digitalmars.D:143998), a
écrit :
>> void readFrom(const(char)[] delegate(size_t) stream,
>> in char[] format = null);
>>
>> -format is the usual format specifier.
>> -stream is a delegate that takes a size_t argument, discards as many
>> char
On Tue, 06 Sep 2011 08:18:15 -0400, Christophe
wrote:
size_t readFrom(const(char)[] data, size_t start); // same as
readUntil delegate
What happens if the buffer data get exhausted ? The function calling
readFrom has no way to know how many characters to put into data to
allow the read.
W
> size_t readFrom(const(char)[] data, size_t start); // same as
> readUntil delegate
What happens if the buffer data get exhausted ? The function calling
readFrom has no way to know how many characters to put into data to
allow the read.
What is the point of start ?
We could use a delegate to
On Sun, 04 Sep 2011 13:51:52 -0400, Robert Jacques
wrote:
On Sun, 04 Sep 2011 00:06:47 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major ineffic
On 2011-09-05 20:37, Marco Leise wrote:
Am 05.09.2011, 19:51 Uhr, schrieb Sean Kelly :
Right. Which is why I've suggested in the past that we may want to use
the serialization calls for toString.
I'm highly skeptical to say the least :). I know there are languages
that serialize solely through
Am 05.09.2011, 19:51 Uhr, schrieb Sean Kelly :
On Sep 3, 2011, at 9:06 PM, Andrei Alexandrescu wrote:
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and composability
On Sep 3, 2011, at 9:06 PM, Andrei Alexandrescu wrote:
> On 8/30/11 8:59 PM, Paul D. Anderson wrote:
>> Can someone clarify for me the status and/or direction of string
>> formatting in D?
> [snip]
>
> I agree there are major inefficiencies and composability problems caused by a
> blind toString
On Sep 3, 2011, at 2:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a standard way to handle it, no
maintenance programmer will
On 09/05/2011 03:29 PM, Andrei Alexandrescu wrote:
On 9/5/11 8:38 AM, Timon Gehr wrote:
On 09/04/2011 05:46 AM, Andrei Alexandrescu wrote:
On 9/3/11 4:40 PM, Timon Gehr wrote:
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void del
On 09/05/2011 03:33 PM, Andrei Alexandrescu wrote:
On 9/5/11 12:22 AM, Walter Bright wrote:
On 9/4/2011 7:34 PM, Andrei Alexandrescu wrote:
On 9/4/11 22:20 EDT, kenji hara wrote:
2011/9/4 Andrei Alexandrescu:
There are suggestions to add this method to Object:
void writeTo(void delegate(cons
On 9/5/11 12:22 AM, Walter Bright wrote:
On 9/4/2011 7:34 PM, Andrei Alexandrescu wrote:
On 9/4/11 22:20 EDT, kenji hara wrote:
2011/9/4 Andrei Alexandrescu:
There are suggestions to add this method to Object:
void writeTo(void delegate(const(char)[]) sink, string format = null);
I think co
On 9/5/11 8:38 AM, Timon Gehr wrote:
On 09/04/2011 05:46 AM, Andrei Alexandrescu wrote:
On 9/3/11 4:40 PM, Timon Gehr wrote:
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.con
On 09/04/2011 05:46 AM, Andrei Alexandrescu wrote:
On 9/3/11 4:40 PM, Timon Gehr wrote:
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody want
On 9/4/2011 7:34 PM, Andrei Alexandrescu wrote:
On 9/4/11 22:20 EDT, kenji hara wrote:
2011/9/4 Andrei Alexandrescu:
There are suggestions to add this method to Object:
void writeTo(void delegate(const(char)[]) sink, string format = null);
I think const void toString(scope void delegate(cons
2011/9/5 Timon Gehr :
> On 09/05/2011 04:30 AM, kenji hara wrote:
>> char[20] buf;
>> char[] result = std.string.sformat(sink[], "%s", obj); // When
>> buf.length is insufficient, FormatError is thrown
>
> I think throwing an Error might be overkill, an Exception should suffice.
I thought the sam
On 09/05/2011 04:30 AM, kenji hara wrote:
I have already posted some pull requests around formatting.
#126Improve std.format.formatValue (-> already merged)
#230Issue 6448 - writef("%05d", BigInt) problem (-> already merged)
#231Issue 6595 - std.string.format() and sformat() are ob
On 9/5/11 4:20 AM, kenji hara wrote:
I think const void toString(scope void delegate(const(char)[]) sink,
string format = null); is more better than that, even if it is
different from DIP9.
That is already used in std.bigint, std.complex, and std.format
already support it.
Requiring only a scop
On 9/4/11 22:20 EDT, kenji hara wrote:
2011/9/4 Andrei Alexandrescu:
There are suggestions to add this method to Object:
void writeTo(void delegate(const(char)[]) sink, string format = null);
I think const void toString(scope void delegate(const(char)[]) sink,
string format = null); is more b
On 09/05/2011 04:20 AM, kenji hara wrote:
2011/9/4 Andrei Alexandrescu:
There are suggestions to add this method to Object:
void writeTo(void delegate(const(char)[]) sink, string format = null);
I think const void toString(scope void delegate(const(char)[]) sink,
string format = null); is mor
I have already posted some pull requests around formatting.
#126Improve std.format.formatValue (-> already merged)
#230Issue 6448 - writef("%05d", BigInt) problem (-> already merged)
#231Issue 6595 - std.string.format() and sformat() are obsolete
#235Change toString signature takin
2011/9/4 Andrei Alexandrescu :
> There are suggestions to add this method to Object:
>
> void writeTo(void delegate(const(char)[]) sink, string format = null);
I think const void toString(scope void delegate(const(char)[]) sink,
string format = null); is more better than that, even if it is
differ
On Fri, 02 Sep 2011 19:46:28 +0200, Steven Schveighoffer
wrote:
I think the library might be able to, in the future, deal with templated
writeTo, but there are many things that would need changing.
This would require compiler magic, not just library features. Templates
need to be instantia
On Sun, 04 Sep 2011 00:06:47 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and composability problems caused
by a blind toString()
Am 04.09.2011, 06:06 Uhr, schrieb Andrei Alexandrescu
:
1. Okay, this takes care of streaming text. How about streaming in
binary format?
Doesn't that come down to using a serialization API like Orange?
- The text format protocols I used all worked with primitive types and
have their own
On 2011-09-04 06:24, Steven Schveighoffer wrote:
On Sun, 04 Sep 2011 00:06:47 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and com
On 2011-09-04 06:06, Andrei Alexandrescu wrote:
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and composability problems caused
by a blind toString() that creates a who
On Sun, 04 Sep 2011 00:06:47 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and composability problems caused
by a blind toString
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and composability problems caused
by a blind toString() that creates a whole new string without any
assistance. So we nee
On Fri, 02 Sep 2011 19:38:23 -0400, Timon Gehr wrote:
On 09/02/2011 07:46 PM, Steven Schveighoffer wrote:
It's arguable that the value of this interface is very low -- currently
it enables things like the builtin sort property on arrays (which I
think should be abolished ASAP), and allows AA's
On 9/3/11 4:40 PM, Timon Gehr wrote:
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a
On Saturday, September 03, 2011 17:03:33 Paul D. Anderson wrote:
> kenji hara Wrote:
> > 2011/8/31 Jonathan M Davis :
> > > Unfortunately however, the proposal seems to have gone nowhere thus
> > > far. Until it does, pretty much every object is just going to use
> > > toString without parameters,
kenji hara Wrote:
> 2011/8/31 Jonathan M Davis :
> > Unfortunately however, the proposal seems to have gone nowhere thus far.
> > Until
> > it does, pretty much every object is just going to use toString without
> > parameters, and the problems with BigInt's toString remain. However, if the
> > p
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a standard way to handle it, no
mainten
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a standard way to handle it, no
maintenance programmer will be confused by alias.
it need
>>> 1. provide an alias void delegate(const(char)[]) Sink; This should
>>> be in std.conv; or std.format;, because nobody wants to add it to
>>> every single module and if there is a standard way to handle it, no
>>> maintenance programmer will be confused by alias.
>>
On 09/03/2011 01:38 AM, Timon Gehr wrote:
I would be very happy to see struct RTTI go away, together with built-in
sort. Are there other features that rely on struct RTTI or is it only
built-in sort and AAs?
And the GC that needs to call destructors obv.
On 09/02/2011 07:46 PM, Steven Schveighoffer wrote:
On Fri, 02 Sep 2011 13:17:02 -0400, Timon Gehr wrote:
On 09/02/2011 06:15 PM, Steven Schveighoffer wrote:
On Fri, 02 Sep 2011 12:04:08 -0400, Timon Gehr
wrote:
2. the format parameter should be completely optional in the signature.
This
On 09/02/2011 11:15 PM, kenji hara wrote:
2011/8/31 Jonathan M Davis:
Unfortunately however, the proposal seems to have gone nowhere thus far. Until
it does, pretty much every object is just going to use toString without
parameters, and the problems with BigInt's toString remain. However, if the
Kenji Hara:
> I have posted pull request to fix BigInt's formatting with writef(ln)
> <- formattedWrite().
> https://github.com/D-Programming-Language/phobos/pull/230
You are doing good work! I hope to see your patches in the final release of DMD
2.055!
Bye,
bearophile
2011/8/31 Jonathan M Davis :
> Unfortunately however, the proposal seems to have gone nowhere thus far. Until
> it does, pretty much every object is just going to use toString without
> parameters, and the problems with BigInt's toString remain. However, if the
> proposal actually gets implemented,
On 2011-09-02 19:16, Andrej Mitrovic wrote:
On 9/2/11, Jacob Carlborg wrote:
Note that to!string and/or write(f)(ln) could be implemented to inspect
the fields and just print them in some standard format. This would allow
you to skip implementing toString/writeTo in simple cases like the above.
On Fri, 02 Sep 2011 13:17:02 -0400, Timon Gehr wrote:
On 09/02/2011 06:15 PM, Steven Schveighoffer wrote:
On Fri, 02 Sep 2011 12:04:08 -0400, Timon Gehr
wrote:
2. the format parameter should be completely optional in the signature.
This is probably impossible. Just for the object case alo
On 09/02/2011 06:15 PM, Steven Schveighoffer wrote:
On Fri, 02 Sep 2011 12:04:08 -0400, Timon Gehr wrote:
On 09/02/2011 03:47 PM, Steven Schveighoffer wrote:
The sink type could be aliased. But this is really getting into minor
issues :) The amount of power and performance you get by switch
On 9/2/11, Jacob Carlborg wrote:
> Note that to!string and/or write(f)(ln) could be implemented to inspect
> the fields and just print them in some standard format. This would allow
> you to skip implementing toString/writeTo in simple cases like the above.
http://codepad.org/1PZY7YTX
But I'm pr
On Fri, 02 Sep 2011 12:04:08 -0400, Timon Gehr wrote:
On 09/02/2011 03:47 PM, Steven Schveighoffer wrote:
The sink type could be aliased. But this is really getting into minor
issues :) The amount of power and performance you get by switching to
writeTo is well worth the extra parameters.
On Fri, 02 Sep 2011 11:46:19 -0400, Timon Gehr wrote:
On 09/02/2011 03:59 PM, Steven Schveighoffer wrote:
On Fri, 02 Sep 2011 06:17:53 -0400, Timon Gehr
wrote:
On 09/02/2011 03:29 AM, Don wrote:
If you're concerned about speed, the writeTo method is much quicker,
since it doesn't requ
On 09/02/2011 03:47 PM, Steven Schveighoffer wrote:
On Thu, 01 Sep 2011 17:09:30 -0400, Timon Gehr wrote:
On 09/01/2011 10:57 PM, Steven Schveighoffer wrote:
On Thu, 01 Sep 2011 16:26:55 -0400, Timon Gehr
wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On
On 09/02/2011 03:59 PM, Steven Schveighoffer wrote:
On Fri, 02 Sep 2011 06:17:53 -0400, Timon Gehr wrote:
On 09/02/2011 03:29 AM, Don wrote:
If you're concerned about speed, the writeTo method is much quicker,
since it doesn't require any heap activity at all.
allocating a new string on
On Fri, 02 Sep 2011 06:17:53 -0400, Timon Gehr wrote:
On 09/02/2011 03:29 AM, Don wrote:
If you're concerned about speed, the writeTo method is much quicker,
since it doesn't require any heap activity at all.
allocating a new string on the heap always requires heap activity. I was
bench
On Thu, 01 Sep 2011 17:09:30 -0400, Timon Gehr wrote:
On 09/01/2011 10:57 PM, Steven Schveighoffer wrote:
On Thu, 01 Sep 2011 16:26:55 -0400, Timon Gehr
wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Obje
On 09/02/2011 03:29 AM, Don wrote:
On 01.09.2011 23:35, Timon Gehr wrote:
On 09/01/2011 11:15 PM, kennytm wrote:
Timon Gehr wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toStrin
On 2011-09-01 22:26, Timon Gehr wrote:
I am not convinced:
struct S{
int x,y,z;
void writeTo(void delegate(const(char)[]) sink, string format = null){
sink("(");
.writeTo(x,sink,"d"); // still no UFCS
sink(", ");
.writeTo(y,sink,"d");
sink(", ");
.writeTo(z,sink,"d");
sink(")");
}
string toStri
On 01.09.2011 23:35, Timon Gehr wrote:
On 09/01/2011 11:15 PM, kennytm wrote:
Timon Gehr wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
On 09/01/2011 11:15 PM, kennytm wrote:
Timon Gehr wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
I have never understood the rationale
Timon Gehr wrote:
> On 09/01/2011 09:41 PM, Don wrote:
>> On 31.08.2011 14:35, Timon Gehr wrote:
>>> On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
>>>
>>> I have never understood the rationale behind depreca
On 09/01/2011 10:57 PM, Steven Schveighoffer wrote:
On Thu, 01 Sep 2011 16:26:55 -0400, Timon Gehr wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
dep
On Thu, 01 Sep 2011 16:26:55 -0400, Timon Gehr wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
I have never understood the rationale beh
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
I have never understood the rationale behind deprecating toString once
we have writeTo. Why should
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
I have never understood the rationale behind deprecating toString once
we have writeTo. Why should it be deprecated?
Code bloat. Eve
On Tue, 30 Aug 2011 19:41:37 -0700, Jonathan M Davis wrote:
> On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
>> Can someone clarify for me the status and/or direction of string
>> formatting in D?
>>
>> We've got:
>>
>> 1. toString, the object method with no parameters. 2. toString
On 08/31/2011 11:00 PM, Paul D. Anderson wrote:
Paul D. Anderson Wrote:
Can someone clarify for me the status and/or direction of string formatting in
D?
We've got:
1. toString, the object method with no parameters.
2. toString(sink, format)
3. to!String()
4. format
5. writef/writefln
6. wri
Paul D. Anderson Wrote:
> Can someone clarify for me the status and/or direction of string formatting
> in D?
>
> We've got:
>
> 1. toString, the object method with no parameters.
> 2. toString(sink, format)
> 3. to!String()
> 4. format
> 5. writef/writefln
> 6. write/writeln
>
> I realize th
Am 31.08.2011, 11:13 Uhr, schrieb Jonathan M Davis :
Java has a toString which doesn't take any arguments, and it works fine.
Let's look at Java again. They have BigDecimal, so how does that work?
First of all they added convenience functions akin to "toString()" to
BigDecimal: "toEngineerin
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
I have never understood the rationale behind deprecating toString once
we have writeTo. Why should it be deprecated? toString is great in case
you just want to quickly and
On 08/31/2011 10:51 AM, Don wrote:
On 31.08.2011 09:03, Jonathan M Davis wrote:
On Wednesday, August 31, 2011 08:53:29 Don wrote:
On 31.08.2011 04:41, Jonathan M Davis wrote:
On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of
On Wednesday, August 31, 2011 10:51:14 Don wrote:
> On 31.08.2011 09:03, Jonathan M Davis wrote:
> > On Wednesday, August 31, 2011 08:53:29 Don wrote:
> >> On 31.08.2011 04:41, Jonathan M Davis wrote:
> >>> On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
> Can someone clarify for
On 31.08.2011 09:03, Jonathan M Davis wrote:
On Wednesday, August 31, 2011 08:53:29 Don wrote:
On 31.08.2011 04:41, Jonathan M Davis wrote:
On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
We've got:
On Wednesday, August 31, 2011 08:53:29 Don wrote:
> On 31.08.2011 04:41, Jonathan M Davis wrote:
> > On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
> >> Can someone clarify for me the status and/or direction of string
> >> formatting in D?
> >>
> >> We've got:
> >>
> >> 1. toString,
On 31.08.2011 04:41, Jonathan M Davis wrote:
On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string formatting
in D?
We've got:
1. toString, the object method with no parameters.
2. toString(sink, format)
3. to!String()
4.
Paul D. Anderson:
> Can someone clarify for me the status and/or direction of string formatting
> in D?
>From a practical point of view, a good starting point is to review (and
>eventually fix) and put this into DMD 2.055:
https://github.com/D-Programming-Language/phobos/pull/126
(It doesn't s
On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
> Can someone clarify for me the status and/or direction of string formatting
> in D?
>
> We've got:
>
> 1. toString, the object method with no parameters.
> 2. toString(sink, format)
> 3. to!String()
> 4. format
> 5. writef/writefln
>
Can someone clarify for me the status and/or direction of string formatting in
D?
We've got:
1. toString, the object method with no parameters.
2. toString(sink, format)
3. to!String()
4. format
5. writef/writefln
6. write/writeln
I realize these exist for various reasons, some (1,3) are simpl
81 matches
Mail list logo
