Walter Bright wrote:
> I started a new thread for this:
> 
> "Mike Capp" <mike.capp@gmail.com> wrote in message news:dua67i$12cr$1@digitaldaemon.com...
>> 7. D has all (well, most of) the power of C++
> 
> I see this often and am a bit perplexed by it. What power do you feel is missing?

Nothing significant.

> 
> And what about the missing power in C++ - inline assembler, nested functions, contract programming, unit testing, automatic documentation generation, static if, delegates, dynamic closures, inner classes, modules, garbage collection, scope guard?
> 
> What does D have to do to have more power than C++?

I think besides bugs and template/array-issues D is almost ready. One major thing that's bugging me though is the role of interfaces in D. I've always thought that D should use interfaces like Java does. Still D (according to the BNF-syntax in the docs) introduces protection attributes to class inheritance. OTOH a trivial test case shows that (luckily) they are not implemented (at least not the way C++ uses them). IMHO they're not welcome at all, if we are going to support accessing classes via interface references:

 interface foo { (public) void abc() { ... } }
 class bar : private foo // something very wrong here
 {}

 void main() {
  foo obj = new bar();
  obj.abc();
 }


The private-protection forces C++ to do a runtime check on the 7. row
and prevent the use. This is complete insanity. Also .sort:ing and other
important operations don't really work currently with the arrays of
interface references to different derived classes of foo. As a
workaround abstract classes must be used as interfaces, but this
prevents the emulation of multiple inheritance. As far as I understand
these interface references aren't as efficient as class references but
they're still damn useful for many practical (non-time critical) purposes.

-- 
Jari-Matti

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dufiff$104d$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dufi31>
>  > Sure I did. My post was an aknowledgement that f(x) doesn't tell you if
> x is
>> in, out, or inout. What exactly are you looking for?
>
> Your opinion on the matter, perhaps?  What you posted was kind of indirectly related to the subject, but didn't really tell me how you feel about out/inout at the call site.  To me, it came across as defensive, and a bit evasive.
>
> Please reply with your feelings on the matter of out/inout at the call site, and if that would make code more readable/inspectible/self-documenting.

I don't really have any feelings on the matter. Note that f(x) also doesn't tell you the return type of f(), or the type of x, or if any implicit conversions happened to x as an effect of making a parameter out of it.

There are over 100 posts a day in these n.g's. It's simply impossible for me to give detailed, intelligent, solid responses to every point. It's not possible to give each the attention they deserve. The best I can do is try to deal with the most important topics, and I'm sure nobody will agree with me nor anyone else as to which are the most important ones. It's not even possible for *me* to determine which are the most important ones.

Important things get overlooked. Messages scroll off before being dealt with. I'm sorry about that.

Some things that do help *a lot* are:

1) Thomas' dstress
2) Brad's bugzilla
3) Helmut's wiki

because they serve as distillers of wheat from chaff, and things don't scroll off in them. They also each share a common characteristic - someone took the initiative and took charge of them.

In article <due89q$2c2b$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dudept$19qp$1@digitaldaemon.com...
>> And in D, f(x) can be visually ambiguous as well - is the parameter in, out, or inout?
>
>At least you know it's a function call, rather than a declaration of x of type f!
>

Is this the primary reason that implicit ctors for fundamental types have not been implemented?

If so, I guess I don't see how 'double i = double(10.25);' would be seen as any more ambiguous or make code any harder to read than ctors or static opCalls for UDT's?

With implicit fundamental types ctor syntax, 'static if(is(...))' wouldn't be
needed as much to support UDT's for templates like this (and also make template
code easier to develop, read and maintain, IMO):

//import std.math;
//template circumference(T)
//{
//    T circumference(T radius)
//    {
//        static if(is(T : real))
//            return PI * radius * 2;
//        else
//            return T(PI) * radius * T(2);
//    }
//}

Thanks,

- Dave

With all due respect, in my experience this may be nice but can be just as detrimental.  As you and he said, he's going to miss some...

I was able to field 500 posts a day, but when 900 were being posted a day that just wasn't enough.  Most commonly, I would read a topic, give it to my subconscious, mark it back unread, and keep going.  If I said, "I'm thinking about it" (which I did try, by the way) I would be bombarded with personal messages from those I didn't make such responses to.  Because, then, they knew I wasn't even reading them.

It was much worse.  I'd rather leave it to mystery than make someone feel like I'm ignoring them when I'm just trying to get to everything I can.

I realize you want responses; I want responses.  I also know those who asked me questions wanted responses.  But in the end, it's patience that's the answer - not "I'm still looking into that."

Just my opinion, of course.

-[Unknown]

> But sometimes a simple "I'm still looking into that" would be nice.

Walter Bright wrote:

> Should D support trigraphs?


No. Period!



A language that is 32-bit only (meaning no 16-bit processors), just does not need them.

32-bit development is done on 32-bit systems. And today all such systems use character sets large enough to _at_least_ support the full USASCII character set, if not even Unicode as such.

Trigraphs were [thought to be] needed on 7-bit character set systems in "Foreign Countries". But that's history there too by now.

Take it from the trenches! :-)

----

There's another issue that some might start arguing. That's keyboard layouts.

On exotic layouts some of the main trigraph "target" characters are either impossible or just awkward to type. But in those cases it is usual to switch between a "native" and the "us" character layout for programming. Single click keyboard layout switching is becoming standard issue even outside Linux/Windows/Mac.

The C-family of languages is famous for its choice of several source code characters being based on their location on the keyboard. The people who'd like trigraphs for layout reasons, are likely to have other problems too: where are '*@"$&` and some others?

Same problem, but no trigraphs for them.

----

A historical note: They never were more than a make-believe solution for "other peoples' problem". In the good Old Days, when we would have needed trigraphs, we still didn't use them.

> /*
>   A std C program that includes all the defined trigraphs,
>   Copied from Wikipedia
> */
> ??=include <stdio.h> // #
> 
> int main(void)
> ??< // {
>         char n??(5??); // [ and ]
> 
>         n??(4??) = 'a';
>         printf("%c??/n", n??(4??)); // ??/ = \
>                 return ??- 0 ??' 1 ??! 2; // ~, ^ and |
> ??> // }

Now, here's how we used to write the same code, at the time. Granted, it's not nice looking to the untrained eye, but using trigraphs (as above) would have made the code simply useless.

> /*
>   The same as above.
> */
> £include <stdio.h>
> 
> int main(void)
> ä
>         char Ä5Å;
> 
>         nÄ4Å = 'a';
>         printf("%cÖn", nÄ4Å);
>                 return Ü 0 ü 1 ö 2;
> å

Incidentally, this same technique was usable (and was used) in all of the countries where non-US versions of ASCII were in use. It's based on the fact that any replacement of a US character was both typeable and printable. :-)

----

Last, but not least: the problem trigraphs seek to remedy, is such pre-ancient history that it should not even be mentioned with a modern programming language.

Walter Bright wrote:
> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dudept$19qp$1@digitaldaemon.com...
> 
>>And in D, f(x) can be visually ambiguous as well - is the parameter in, out, or inout?
> 
> 
> At least you know it's a function call, rather than a declaration of x of type f! 
> 
> 

You can declare basic datatypes like this:

#    int(x);
#
#    x = 10;

ironically, if you use an alias, you can't do it

# alias int t;
#
# t(x1);
# x1 = 10;

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dufpnl$1ebk$1@digitaldaemon.com...
> Just my opinion, of course.

Sometimes, just my responding to a post generates a whole bunch of new posts that need responding too <g>.

Johan Granberg wrote:
> Ben Phillips wrote:
> 
>> In article <dubpge$u3r$1@digitaldaemon.com>, Johan Granberg says...
>>
>>>>> 1. const parameters and member functions
>>>>>
>>>>> Countless times this saved me. I just can't imagine references being
>>>>> passed in and out of functions without something explicitly saying that
>>>>> the function is expected or not to modify it.
>>>
>>> You did not answer the above statement and i have seen this repeated all over this thread along with destructors in structs.
>>>
>>
>> A method can explicitly say that it will modify a reference by using "out" and
>> "inout".
>>
>> I've never cared much for const member methods, so I'm confused as to how a lack
>> of them can cause such a problem. Can you give an example?
>>
>>
> It is not const methods so much as const in parameters.
> 
> class A
> {
>  int bar=1;//bar should bee read only
> }
> 
> void foo(in i a)//I want a to bee readonly
> {
>     i.bar=2;//here the value should not be writable but since a is
>             //a reference it is
> }
> 
> A a=new A;//bar is 1
> foo(a);
> print(a.bar);//prints 2
> 
> It is not so very usefull in smal examples but if you have a large program and do that by mistake it could cause a bug. Basicaly it is a message from the writer of a class to it's users of how member are to bee used, and aditionaly it has compiler suport to catch typos and mistakes, if a user realy want to change the data against the orginal authors recomendations he can use a explicit cast.

Maybe I'm missing something, but why don't you just mak A.bar private?

Walter Bright wrote:
> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dufpnl$1ebk$1@digitaldaemon.com...
>> Just my opinion, of course.
> 
> Sometimes, just my responding to a post generates a whole bunch of new posts that need responding too <g>. 

Yup.  You're the metaphorical butterfly in these forums ;-)


Sean

I suppose that might indeed even happen with a response like, "I'm thinking about it" - if not as often.

-[Unknown]


> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dufpnl$1ebk$1@digitaldaemon.com...
>> Just my opinion, of course.
> 
> Sometimes, just my responding to a post generates a whole bunch of new posts that need responding too <g>. 
> 
>