November 17, 2005
On Thu, 17 Nov 2005 01:16:37 -0800, Kris <fu@bar.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote
>>
>> Because "auto" is a request by the programmer for the compiler to
>> pick/guess the type,
>
> You'd have us support your notion that D deliberately introduce aspects of guesswork into our code ~ it's not enough that we can do it ourselves.

If 'auto' isn't guessing what type I want, what is it doing? Would you rather say it picks a type? Personally, I see no difference, it's deciding on a type based on the information provided on the RHS. That information is a string literal (undecorated) and that gives it 3 equal choices, it picks char[] in these cases. It's choice is consistent, but it's still a guess as to what the programmer wants.

> void write (char[] x){}
> void write (wchar[] x){}
>
> void main()
> {
>     auto ascii = "ascii";       // implicit
>     auto wide = "wide"w;  // explicit
>
>     write (ascii);         // implicit :: good

This line does nothing implicit, the variable 'ascii' has a type by this point, the implicit behaviour (if you can even call what 'auto' does implicit) happens above where the compiler picks a type for the data supplied.

> Regan ~ I generally don't see your postings. When the NG started getting
> literally hundreds of posts per day I instigated filtering. As a result your posts, and probably many others, get dropped. This particular response is
> prompted by a third-party, so here I am.

I thank the 3rd party. I had realised you were filtering my posts.

> In reviewing your related posts, I'm not seeing you offer much of anything constructive. You are certainly welcome to critique and poke holes at my
> suggestions. That's the easy position to adopt.But, either way, it appears you'd rather just post a whole lot of negativity to this thread than /possibly/ discover a means of helping D become more
> consistent and/or simpler.

I'm confused, this is a discussion right? where we each share our opinions on the merits *and* faults of a suggested change in how D operates. My position on the current suggestion *is* a negative one. Don't confuse my position on this suggestion with my position on looking for a solution. I would very much like for there to be a solution to the problem, I just don't think this one is it.

> For example, you might
> provide a set of reasons as to why your claim is of real practical benefit :: the claim that undecorated literals /should/ be treated differently
> depending on usage

A: auto p = "test";
B: write("test");

The difference between A and B is that in A the programmer has explicitly (via 'auto') asked the compiler to pick a type for the data "test". In B the programmer has not asked the compiler to 'pick' a type.

The reason why picking a type in B is dangerous is there exists the possibility that the type the compiler picks causes behaviour that the programmer did not intend.

A simple example:

void write(char[] s)  { printf("1"); }
void write(wchar[] s) { printf("2"); }
void write(dchar[] s) { printf("3"); }

write("test");

the type the compiler picks causes one of 3 different things to happen, the programmer has not explicitly specified the behaviour they require, this is an error.

Consider this example:

auto p = "test";
write(test);

The reason this is _not_ the same as the example above is that in this case the programmer has asked the compiler to pick a type, the compiler does so in a consistent manner, making the result predicatable.

Regan
November 17, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message
> On Thu, 17 Nov 2005 01:16:37 -0800, Kris <fu@bar.com> wrote:
>>
>>     auto ascii = "ascii";       // implicit
>>     auto wide = "wide"w;  // explicit
>>
>>     write (ascii);         // implicit :: good
>
> This line does nothing implicit, the variable 'ascii' has a type by this point, the implicit behaviour (if you can even call what 'auto' does implicit)

It is /derived/ from an implict assertion, rather than an explicit one; derived from what you refer to as a "guess". Quite different altogether from the explicit case. I made the (mistaken) assumption that would be understood. My apologies.


>  I had realised you were filtering my posts.

I see; so you've been posting "replies" couched in terms of a "discourse", armed with the full knowledge I'm not seeing them. That seems rather sly, Regan.


> I'm confused, this is a discussion right?

How can you claim a discussion of my point(s) whilst fully aware I don't see your posts <g>.

It's an open forum, if that's what you mean.

As to negativity and discourse; people gravitate to threads where there's constructive back and forth. On the other hand, they are turned away by a barrage of the contrary. It would not be the first time you've loaded a topic out of seemingly personal interest alone.


> I  would very much like for there to be a solution to the problem, I just don't think this one is it.

Hurrah! You acknowledge the existance of a problem. Let's hear a solution!


> B: write("test");
>
>  In B the programmer has not asked the compiler to 'pick' a type.

You think so? Just because you've become used to thinking that way does not mean it should not imply this:

B: write (auto "test");

Here's why:

In the /absence/ of an explicit storage class, the compiler perhaps ought to treat all string-literals the same. Just as it currently does when there /is/ explicit storage class. Consistency is a good thing. Less special cases is a good thing. Simplicity is a good thing. You're apparently claiming the opposite.


> The reason why picking a type in B is dangerous is there exists the possibility that the type the compiler picks causes behaviour that the programmer did not intend.

It is no more "dangerous" than the use of auto. Additionally, it reduces the number of rules to remember, promotes consistency, and eliminates a known problem with op-overloads.

BTW; your usage of "dangerous" tends to associate lots of negative connotation (no surprise). You're apparently quite happy to accept that connotation where auto is used, yet not in the other case. It seems you are intent on splitting hairs, Regan.


> The reason this is _not_ the same as the example above is that in this case the programmer has asked the compiler to pick a type.

Again you've completely ignored the issue of the special case(s) plus related problems, and blandly recited what the compiler does right now. That's hardly progressive. I'll repeat: Consistency is a good thing. Less special cases is a good thing. Simplicity is a good thing. You're claiming the opposite.

How about it? Let's hear something a bit more constructive, eh?


November 17, 2005
On Thu, 17 Nov 2005 11:31:37 -0800, Kris <fu@bar.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> On Thu, 17 Nov 2005 01:16:37 -0800, Kris <fu@bar.com> wrote:
>>>
>>>     auto ascii = "ascii";       // implicit
>>>     auto wide = "wide"w;  // explicit
>>>
>>>     write (ascii);         // implicit :: good
>>
>> This line does nothing implicit, the variable 'ascii' has a type by this
>> point, the implicit behaviour (if you can even call what 'auto' does
>> implicit)
>
> It is /derived/ from an implict assertion, rather than an explicit one;
> derived from what you refer to as a "guess". Quite different altogether from the explicit case.

The point I was trying to make is that this case:
  auto ascii = "ascii";

is identical to this case:
  char[] ascii = "ascii";

when it gets to this call:
  write(ascii);

By "identical" I do not mean they are the same type. I mean that at the call site the type is known/fixed and an overload is called. The same would be true even if auto picked wchar[] or dchar[]. The type is fixed _before_ the attempt to resolve the overload.

This case:
  write("test");

is different. The type is determined by the available overloads, it's not known/fixed before the attempt to resolve the overload.

--

I agree with you below, the risk involved in "auto" and in picking a type at the call to write("test") are the same, the difference is that the programmer has to explicitly use "auto" for those risks to be present.

> I made the (mistaken) assumption that would be
> understood. My apologies.

(Snide remarks I will simply snip and ignore in future - they have no effect on me or this discussion)

>>  I had realised you were filtering my posts.
>
> I see; so you've been posting "replies" couched in terms of a "discourse", armed with the full knowledge I'm not seeing them. That seems rather sly,
> Regan.

My posts were not intended soley for you, this is a public news group. I didn't have "full knowledge" it was more of a suspician. Lets put it this way, I was not surprised to find you were filtering my posts.

>> I'm confused, this is a discussion right?
>
> How can you claim a discussion of my point(s) whilst fully aware I don't see your posts <g>.

See above.

> It's an open forum, if that's what you mean.
>
> As to negativity and discourse; people gravitate to threads where there's
> constructive back and forth. On the other hand, they are turned away by a
> barrage of the contrary. It would not be the first time you've loaded a
> topic out of seemingly personal interest alone.

(combining this with my answer below)

>> I  would very much like for there to be a solution to the problem, I just
>> don't think this one is it.
>
> Hurrah! You acknowledge the existance of a problem. Let's hear a solution!

If I had another idea you'd have heard it long ago, in fact, you did:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5405
(or would have were you not filtering my posts)
(note Walters reply to my post)

The simple fact of the matter is that I believe the current behaviour is the best solution _so far_, my comments have been in comparing the suggested solutions with that behaviour. If it appears that I am negative about these ideas, that is the reason why.

Don't confuse my position on the latest idea, with my position on finding a solution the two are not the same thing.

There have been no less than 11 people posting to this thread and the thread in digitalmars.D, it doesn't look like anyone has been turned away from posting on this topic. That said, if anyone at all feels that I have stopped them from posting for any reason, my email address is valid and I would like to hear from you (you have my word that I will keep your email private (address and contents) and not reply in any way, except to thank you for your time)

>> B: write("test");
>>
>>  In B the programmer has not asked the compiler to 'pick' a type.
>
> You think so? Just because you've become used to thinking that way does not mean it should not imply this:
>
> B: write (auto "test");
>
> Here's why:
>
> In the /absence/ of an explicit storage class, the compiler perhaps ought to treat all string-literals the same. Just as it currently does when there
> /is/ explicit storage class.

Key word: "perhaps". Perhaps it should, however if it did it "would" add the potential for a subtle bug.
That is all I am trying to say here. That is the sole complaint I have with this idea, that is the sole reason I prefer the current behaviour.

> Consistency is a good thing. Less special cases is a good thing. Simplicity is a good thing.

I agree completely.

> You're apparently claiming the opposite.

Not true and patently illogical:
 - I prefer simplicity.
 - I don't think it's possible to treat all string literals the same.
   (for reasons posted here and previously)

The two points of view can exist simultaneously as they are not mutually exclusive.
I would very much like a simple solution, sadly there doesn't seem to be one, yet.

>> The reason why picking a type in B is dangerous is there exists the
>> possibility that the type the compiler picks causes behaviour that the
>> programmer did not intend.
>
> It is no more "dangerous" than the use of auto.

Correct. But auto is used explicitly by the programmer, they have chosen to accept the risk. If a bug results it's also more likely they will track it down because when hunting for it they will see "auto" and know that at that point a "type was chosen".

In short while the risk is the same with "auto" and picking at type for write("test") they are still different in that one is explicit(represented in the code), the other implcicit(silent).

> Additionally, it reduces the number of rules to remember, promotes consistency, and eliminates a known
> problem with op-overloads.

Sure, and I'm all for that, the problem remains that this solutions adds the possibility of a silent, hard to find bug. I accept the fact that this bug is unlikely. If you are prepared to accept this risk, that's fine. I would _prefer_ not to.

My feeling is that a compiler shouldn't necessarily accept this risk for us, unless of course the bulk of D programmers are prepared to accept it. Perhaps a poll is in order? In the end Walter has to judge this and make the decision.

> BTW; your usage of "dangerous" tends to associate lots of negative
> connotation (no surprise).

http://dictionary.reference.com/search?q=dangerous
"Involving or filled with danger; perilous."

I agree, dangerous implies more risk that there is. "slightly risky" is much more accurate.

> You're apparently quite happy to accept that
> connotation where auto is used, yet not in the other case.

The other case?

I believe:
  write("test"); //choosing a type
and
  auto p = "test";
  write(p);

are equally risky(slightly). The difference is that one is used explicitly, the other occurs silently/implicitly.

>> The reason this is _not_ the same as the example above is that in this
>> case the programmer has asked the compiler to pick a type.
>
> Again you've completely ignored the issue of the special case(s) plus
> related problems, and blandly recited what the compiler does right now.

Sorry, please let me know to which case you're referring and I'll address it now.

> That's hardly progressive. I'll repeat: Consistency is a good thing. Less
> special cases is a good thing. Simplicity is a good thing. You're claiming the opposite.

Nope, never have, likely never will.

Regan
November 18, 2005
"Regan Heath" <regan@netwin.co.nz> wrote
>> "Kris" wrote
>>
>> I made the (mistaken) assumption that would be
>> understood. My apologies.
>
> (Snide remarks I will simply snip and ignore in future - they have no effect on me or this discussion)

Good grief, Regan  ...  R.e.a.d. a.g.a.i.n. s.l.o.w.l.y.

The words "mistake" and "apology" are represented within that sentence. If you choose to get upset by my writing, then don't read it. Period. It'd make us both happier :-)


>>>  I had realised you were filtering my posts.
>>
>> I see; so you've been posting "replies" couched in terms of a
>> "discourse", armed with the full knowledge I'm not seeing them. That
>> seems rather sly,
>> Regan.
>
> My posts were not intended soley for you, this is a public news group. I didn't have "full knowledge" it was more of a suspician.

Yawn; backtrack away. It's not what you stated above.


>> Hurrah! You acknowledge the existance of a problem. Let's hear a solution!
>
> If I had another idea you'd have heard it long ago, in fact, you did: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5405

Hmmm. You're recycling comments about transcoding, file encoding, compiler swiches, and everything else that those before you had suggested. There's no mention anywhere of the subtle problems created by the current approach, nor is there any mention of the special cases highlighted through this topic. Further, this is not about the "transcoding nightmare" spectre you seem to like tossing around so much (as coined by AJ). It's quite hard to see any relevance in this "idea" you speak of.

You see? It's really very easy to pick holes in someone else's position. You should try to offer a constructive approach to the question in hand, rather than simply trying to misdirect the topic, bemoan change, or being argumentative for the sake of it <g>


> Don't confuse my position on the latest idea, with my position on finding a solution the two are not the same thing.

You'll understand if I wonder about that?


> Key word: "perhaps". Perhaps it should, however if it did it "would" add
> the potential for a subtle bug.
> That is all I am trying to say here. That is the sole complaint I have
> with this idea, that is the sole reason I prefer the current behaviour.

This is about consistency in overload resolution, consistency of usage. less special cases. But it is crystal clear that you can't, or won't, acknowledge that. I'm not particularly interested in attempting to persuade you, when you consistently avoid tackling the existing problems and refuse to even acknowledge any potential upside. One cannot "discuss" with a brick wall.


>> It is no more "dangerous" than the use of auto.
>
> Correct. But auto is used explicitly by the programmer, they have chosen to accept the risk. If a bug results it's also more likely they will track it down because when hunting for it they will see "auto" and know that at that point a "type was chosen".

Yawn. If it's known that *all string literals* have *consistent* behavior, then the "risk" you speak of  is simply equivalent. You're clinging onto unecessary special cases, while completely ignoring potential for upside.


> I accept the fact that this  bug is unlikely. If you are prepared to accept this risk, that's fine. I  would _prefer_ not to.

I understand fully. Yet it seems you can't get past the notion that a change may actually be quite beneficial in a number of related ways. I've spelt them out before, so go and read them if you wish to continue.


> I agree, dangerous implies more risk that there is. "slightly risky" is much more accurate.

Thank you. The sky is /not/ falling.


>> I'll repeat: Consistency is a good thing. Less
>> special cases is a good thing. Simplicity is a good thing. You're
>> claiming the opposite.
>
> Nope, never have, likely never will.

Then since you are still arguing in favor of a special case, you have must have failed to comprehend large portions of the issue. I wish to find a solution to a problem. It seems you just want to split-hairs without understanding what the target problems actually are, hence I fully encourage you to try and understand them a little better. From your comments thus far, I get a strong feeling that you're approaching this from some "theoretical" or "academic" standpoint, rather than having some solid experience with the matter in hand?

And, no; that is not a snide remark.


November 18, 2005
I give up. This particular discussion has degenerated into something which isn't a productive nor enjoyable use of my time. It appears that you and I have a fundamental problem communicating our thoughts and ideas to each other.

For the record:

>> I accept the fact that this  bug is unlikely. If you are prepared toaccept this risk, that's fine. I  would _prefer_ not to.

> I understand fully. Yet it seems you can't get past the notion that a changemay actually be quite beneficial in a number of related ways.

I understand the benefits of the suggested change. I don't agree that they are worth the risks it introduces. This is the singular point of disagreement between us, don't you think?

Regan
November 18, 2005
"Regan Heath" <regan@netwin.co.nz> wrote
>
>I give up. This particular discussion has degenerated into something which
> isn't a productive nor enjoyable use of my time. It appears that you and I have a fundamental problem communicating our thoughts and ideas to each other.

ROFL! I wouldn't claim for a second that I'm without fault; there's plenty of evidence in this NG for that. However, if I could identify one aspect in particular, I'd say it's hard to communicate with those who interpret genuine apologies as snide remarks. That's just silly, so you're on your own with that one. As to your enjoyment :: I suggested earlier that if my writing upsets you, please don't read it. We can do each other a favour here, Regan. That would be a genuinely pleasant thing to do :-)


> For the record:

Yes, it is public record that you must have the last word <g>


> This is the singular point of
> disagreement between us, don't you think?

If it were that simple, Regan, then you might easily have stated that concisely, and precisely, long ago (rather than only in your last post). That would have been cool, and we'd simply agree to disagree. Trival. Finito.

Yet instead, you apparently went to considerable length to debunk each gratuitous little detail, fully armed with the knowledge I would not be seeing your multiple and extensive postings, and thus would not counter them. Some would consider that taking advantage of a situation? Let's just say the motivation appears somewhat suspect. Whatever.

I suspect that you really, really, really, want to have the last word on this. So be my guest  ... if not, then great. I'll wish you well.

To everyone else: apologies for the train-wreck. I'm going to practice some
yoga
(http://svn.dsource.org/projects/mango/trunk/doc/Indian%20and%20Irish%20Yoga.JPG)
and then see what else turns up. Cheers.



November 18, 2005
No comments.

-------------------------------
$ cat outtest.d

import std.stream;

void main()
{
        wchar[] w = "Saatana perkele"w;
        File of = new File;

        of.create("/tmp/outtest.txt");

        of.writefln(w);

        of.close();
}

$ dmd outtest.d
gcc outtest.o -o outtest -lphobos -lpthread -lm

$ ./outtest

$ hexdump -C /tmp/outtest.txt

00000000  53 61 61 74 61 6e 61 20  70 65 72 6b 65 6c 65 0a
|Saatana perkele.|

$


November 18, 2005
This, however does work.
--------------------------------


 $ cat outtest.d

import std.stream;

void main()
{
        wchar[] w = "Saatana perkele"w;
        File of = new File;

        of.create("/tmp/outtest.txt");

        of.write(w);

        of.close();
}

 $ ./outtest

 $ hexdump -C /tmp/outtest.txt

00000000  0f 00 00 00 53 00 61 00  61 00 74 00 61 00 6e 00
|....S.a.a.t.a.n.|
00000010  61 00 20 00 70 00 65 00  72 00 6b 00 65 00 6c 00
|a. .p.e.r.k.e.l.|
00000020  65 00
|e.|
00000022
 $
November 18, 2005
On Fri, 18 Nov 2005 07:37:35 +0200, Georg Wrede wrote:

> No comments.
> 
> -------------------------------
> $ cat outtest.d
> 
> import std.stream;
> 
> void main()
> {
>          wchar[] w = "Saatana perkele"w;
>          File of = new File;
> 
>          of.create("/tmp/outtest.txt");
> 
>          of.writefln(w);
> 
>          of.close();
> }
> 
> $ dmd outtest.d
> gcc outtest.o -o outtest -lphobos -lpthread -lm
> 
> $ ./outtest
> 
> $ hexdump -C /tmp/outtest.txt
> 
> 00000000  53 61 61 74 61 6e 61 20  70 65 72 6b 65 6c 65 0a
>|Saatana perkele.|

I suspect its this bit of code in std.stream ..

  private void doFormatCallback(dchar c) {
    char[4] buf;
    char[] b;
    b = std.utf.toUTF8(buf, c);
    writeString(b);
  }

I always converts your characters to UTF8 encoding before writing them out.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/11/2005 4:54:02 PM
November 18, 2005
On Fri, 18 Nov 2005 16:55:29 +1100, Derek Parnell <derek@psych.ward> wrote:
> On Fri, 18 Nov 2005 07:37:35 +0200, Georg Wrede wrote:
>
>> No comments.
>>
>> -------------------------------
>> $ cat outtest.d
>>
>> import std.stream;
>>
>> void main()
>> {
>>          wchar[] w = "Saatana perkele"w;
>>          File of = new File;
>>
>>          of.create("/tmp/outtest.txt");
>>
>>          of.writefln(w);
>>
>>          of.close();
>> }
>>
>> $ dmd outtest.d
>> gcc outtest.o -o outtest -lphobos -lpthread -lm
>>
>> $ ./outtest
>>
>> $ hexdump -C /tmp/outtest.txt
>>
>> 00000000  53 61 61 74 61 6e 61 20  70 65 72 6b 65 6c 65 0a
>> |Saatana perkele.|
>
> I suspect its this bit of code in std.stream ..
>
>   private void doFormatCallback(dchar c) {
>     char[4] buf;
>     char[] b;
>     b = std.utf.toUTF8(buf, c);
>     writeString(b);
>   }
>
> I always converts your characters to UTF8 encoding before writing them out.

It looks that way. Ideally you should be able to set the default text output format to one of the 3 types.

Currently it appears that we have:
  write       - writes string length, followed by string data.
  writeLine   - writes string data, followed by newline.
  writeString - writes string data.

which do not convert to UTF-8, and:
  writef      - writes formatted data in default output type.

which does.

Regan