On Wednesday, 10 February 2016 at 14:06:02 UTC, Suliman wrote:
> Sorry, but where dump! function can be helpful? What's wrong with writeln?

Formatting complex data automatically makes it a lot easier to see what you're getting. Makes debugging so much easier when your data is actually readable.

Long strings, complex structs, byte arrays, json or xml, these all really need more formatting to read than writeln does.

On 02/10/2016 09:22 AM, Daniel Kozak via Digitalmars-d wrote:
> It is something else. Same as php has echo and var_dump. writeln just
> output value of some variable, but dump will print names and values of
> variables, so you can see structure of your data.

Oh btw one nice thing about dump would be to display strings in "dson" format, i.e. the same way they'd appear in a D declaration. Example:

s = "This is\na\tstring."

writeln(s) would output:

====
This is
a    string.
====

whereas dump!(s) would write:

====
s = "This is\na\tstring."
====


Andrei

I wonder if the addition of another function for printing will confuse some new users.

On Wed, Feb 10, 2016 at 06:51:21PM +0000, w0rp via Digitalmars-d wrote:
> I wonder if the addition of another function for printing will confuse some new users.

Currently I don't see much value in it to justify the costs.

BUT,

there might be a case for it if:

1) It's clear that it's only intended for debugging (i.e., the name should make it clear it isn't for general output, so `dump` rather than `print` would be preferable);

2) It's actually useful for debugging, meaning:

   a) It will use introspection to recursively output aggregate members
   (preferably with field members labelled);

   b) Arrays and AA likewise should be output in the expected format;

   c) Attributes, and perhaps the full type, should be included in the
   output, especially if function pointers and delegates are involved,
   e.g.:

	const(char)[] data = ...;
	int delegate(float) @safe dg;
	dump(data, dg);

   should output something like:

	(const(char)[])"Some string data", (int delegate(float) @safe)0x12345678

   (Why the full type? because it's useful for debugging `auto`
   variables in range-based code and other such code. And also to make
   it absolutely clear that this isn't meant for anything other than
   debugging output.)

   d) It will, optionally, walk recursive data structures and output
   each node in some sensible way.

3) The output format should be standard, readable by default, and should
not need (nor allow) customization. (Otherwise, we might as well go back
to writefln & friends.)


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy

On Wednesday, 10 February 2016 at 18:51:21 UTC, w0rp wrote:
> I wonder if the addition of another function for printing will confuse some new users.

I'm a relatively new D user. For the most part, all I use is writeln because that's what was used in the Hello World examples. I only bother looking for other printing functions when I need them.

Nevertheless, I struggle with some of the documentation in std.stdio. A few functions, like byChunk, are documented in a high-quality way. For others, the situation is not so good. Look at stdout, just says standard output stream. There's no definition of stream anywhere in there, or a link to maybe the wikipedia page on streams. When I google output stream it brings up Java documentation. I happen to know what it means and someone with other programming experience will too, but not a new programmer. Many other functions are documented in a similarly terse fashion.

So no, I don't think adding another function to std.stdio will be confusing ipso facto. Instead, if you think new users will find std.stdio confusing, may I suggest improving the documentation (of both old and new functionality).

On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Feb 10, 2016 at 06:51:21PM +0000, w0rp via Digitalmars-d wrote:
>> I wonder if the addition of another function for printing will confuse
>> some new users.

I can't imagine it would in any significant way. Certainly not if it's named "dump", anyway.

>
> Currently I don't see much value in it to justify the costs.
>
> BUT,
>
> there might be a case for it if:
>
> [...]

I see no non-trivial cost.

I've been using a homemade equivalent of it for years, and I can speak from experience that it's definitely a big help. Not only that, but the only two reasons I've ever had for NOT using it are fixed by this proposal:

- Can now be done without bulky "mixin(...)" at the usage site.

- Built into Phobos so never a need, in any project, to [temporarily or otherwise] tie in a new dependency just for a temporary debugging aid.

I'm hugely in favor of this. Me want.

On 02/10/2016 01:51 PM, w0rp wrote:
> I wonder if the addition of another function for printing will confuse
> some new users.

In my experience:

* two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++)

* two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++)

* two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector<bool> vs vector_bool in C++)

* two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap").

So I think we're safe.

Andrei

On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote:
> 1) It's clear that it's only intended for debugging (i.e., the name
> should make it clear it isn't for general output, so `dump` rather than
> `print` would be preferable);

Those would be two different functions. -- Andrei

On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
> I see no non-trivial cost.

I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei

On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
> >I see no non-trivial cost.
> 
> I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei

Sorry, I meant technical debt.  My point was that this function needs to provide more value than what's effectively just an alias for writefln("%s, %s, %s", x, y, z).


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte