Ary Borenszweig:
> Can't "import std.math : pow;" be added to the current module when this is needed?

Note that this code doesn't compile:

import std.stdio: writeln;
import std.math: pow;

void main() {
    writeln(5.2 ^^ 2);
}


This is what the compiler shows:
test.d(5): Error: undefined identifier module test.std
test.d(5): Error: no property 'math' for type 'void'
Error: no property 'pow' for type 'int'
test.d(5): Error: function expected before (), not __error of type int

Tool completed with exit code 1

Bye,
bearophile

Ary Borenszweig wrote:
> bearophile wrote:
>> 5 ^^ 2 doesn't work yet, I guess it's not implemented yet.
>> But what do I have to import from math to use 5.2 ^^ 2 ?
>> Anyway, the need to explicitly import something to use a built-in operator like ^^ looks like a bad idea.
> 
> A very bad idea indeed! The idea is to save keystrokes...
> 
> Can't "import std.math : pow;" be added to the current module when this is needed?

I'll just explain the situation here. I provided a patch to DMD for opPow, with ^^. The patch was very minimal, since I did not know if Walter would accept it. It's not worth putting a whole lot of effort into something which will just be rejected (and it has less chance of acceptance if it is complicated). In the end, he did include the patch, though without opPowAssign.

I did the absolute bare minimum required to get ^^ working. In my patch, I clearly stated that the requirement to include std.math.pow is temporary. BTW, One of the nice things about ^^ is that we will finally be able to do integer powers without necessarily using floating-point.
All kinds of stuff is still missing. a ^^ b won't be constant-folded, for example.
It's desperately important that the language spec becomes stable before Andrei's book comes out. That leaves only a couple more releases left in D2 where features can be added. Some, like this one, will have rough edges. Don't think of it as fully implemented feature.

== Quote from Don (nospam@nospam.com)'s article
> All kinds of stuff is still missing. a ^^ b won't be constant-folded,
> for example.
> It's desperately important that the language spec becomes stable before
> Andrei's book comes out. That leaves only a couple more releases left in
> D2 where features can be added. Some, like this one, will have rough
> edges. Don't think of it as fully implemented feature.

If we do find bugs in it, should we still file bug reports, or is the feature still so experimental that filing these would just be noise?

dsimcha wrote:
> == Quote from Don (nospam@nospam.com)'s article
>> All kinds of stuff is still missing. a ^^ b won't be constant-folded,
>> for example.
>> It's desperately important that the language spec becomes stable before
>> Andrei's book comes out. That leaves only a couple more releases left in
>> D2 where features can be added. Some, like this one, will have rough
>> edges. Don't think of it as fully implemented feature.
> 
> If we do find bugs in it, should we still file bug reports, or is the feature
> still so experimental that filing these would just be noise?
I just patched the bug you reported. Putting together a test suite mightn't be a bad idea.

On Sat, 05 Dec 2009 05:05:13 +0100, Walter Bright <newshound1@digitalmars.com> wrote:

> Probably the biggest thing is opDispatch!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.053.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.037.zip
>
> Many thanks to the numerous people who contributed to this update.

I get a compile error:
  std\conv.d(2506): Error: undefined identifier module traits.staticIndexOf
Line 2506 in std.conv should be changed from
  if (std.traits.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T)
to
  if (std.typetuple.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T)

-- 
Simen

Simen kjaeraas wrote:
> I get a compile error:
>   std\conv.d(2506): Error: undefined identifier module traits.staticIndexOf
> Line 2506 in std.conv should be changed from
>   if (std.traits.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T)
> to
>   if (std.typetuple.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T)

That change is already in the release. Perhaps you have an old version?

On Sun, 06 Dec 2009 03:35:42 +0100, Walter Bright <newshound1@digitalmars.com> wrote:

> Simen kjaeraas wrote:
>> I get a compile error:
>>   std\conv.d(2506): Error: undefined identifier module traits.staticIndexOf
>> Line 2506 in std.conv should be changed from
>>   if (std.traits.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T)
>> to
>>   if (std.typetuple.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T)
>
> That change is already in the release. Perhaps you have an old version?

So it would indeed seem. Sorry about the noise.

-- 
Simen

On Sat, 5 Dec 2009 10:59:12 -0500, "Nick Sabalausky" <a@a.a> wrote:

>"Max Samukha" <spambox@d-coding.com> wrote in message news:pkvkh5tvvhie0ga61lrpp5qmt53h5ju1t4@4ax.com...
>> On Sat, 5 Dec 2009 10:19:23 -0500, "Nick Sabalausky" <a@a.a> wrote:
>>
>>>"bearophile" <bearophileHUGS@lycos.com> wrote in message news:hfdt87$1num$1@digitalmars.com...
>>>> There's a large number of changes!
>>>> I don't understand what "No more comma operators allowed between [ ]."
>>>> means.
>>>>
>>>
>>>I assume that means:
>>>
>>>int[1,2,3] foo; // <- formerly created an int[3], now (presumably)
>>>disallowed
>>>
>>
>> Was this feature documented anywhere?
>
>I don't think it was ever really a feature, it was just a consequence of the next-to-useless expression "x,y" evaluating to "y" and "int[...] foo;" taking a single value for "...".
>

Ah, it is simply the unfortunate comma expression evaluated to 3. Comma expressions need to go. Thanks.

Max Samukha:
> Ah, it is simply the unfortunate comma expression evaluated to 3. Comma expressions need to go. Thanks.

There are so many design holes in the C language that's the other languages must be really bad to be worse than C :-) Designing languages is hard.

Bye,
bearophile

bearophile wrote:
> Max Samukha:
>> Ah, it is simply the unfortunate comma expression evaluated to 3. Comma expressions need to go. Thanks.
> 
> There are so many design holes in the C language that's the other
> languages must be really bad to be worse than C :-) Designing
> languages is hard.

Appreciating language designs is subjective. IMHO C has a remarkably good design. It has an awkward precedence for the shift operators, an odd syntax for function declaration, a few conversions are messed up... other than that, there's a lot of good things to say about it. I think it's considerably better designed than e.g. Fortran, which is not much older. And look at Pascal - whereas on the outside it looks so clean and well-designed, it is virtually useless in its standard incarnation.

Not wanting to start a language war, but to just say C has plenty of design holes and then patronize it with the comment that designing languages is hard - well, you better have a hell of an argument up your sleeve.


Andrei