Quick question about remove() since I can't test the new release quite yet. Does it return the stored value?  It would be nice if we could do things like this:

int[int] a;
Objecct[int] b;
printf( "removed %i\n", a.remove(1) );
delete b.remove(2);

I grant that the syntax is a bit odd for the delete line, but it saves a double lookup or the need to add a second function for the purpos (erase?).


Sean

Two thumbs up!

-Craig

"Walter" <newshound@digitalmars.com> wrote in message news:d85vju$so2$1@digitaldaemon.com...
> Added inner classes.
>
> http://www.digitalmars.com/d/changelog.html
>
>
> 

In article <d85vju$so2$1@digitaldaemon.com>, Walter says...
>
>Added inner classes.
>
>http://www.digitalmars.com/d/changelog.html
>
>
>

Walter, the following D code now skips on passing in a char[] literal into a function that has both a func(in char[]) and a func(in char *) defined. Is this a new change in D's behavior in handling string literals? Or is this a side-effect / error from the current v0.126 changes?

# // OverLord.d
# private import std.stdio;
#
# int main()
# {
#     char[] s = "char[] var";
#     //printValue(s);  // Works fine.
#     printValue("char[] literal"); //Now a problem without a cast(char[])
#
#     return 0;
# }
#
# void printValue( in char[] s)
# {
#     writefln("printValue(in char[]) called, value=%s", s);
# }
#
# void printValue( in char* s)
# {
#     writefln("printValue(in char*) called, value=%s", s);
# }

Output:
--------
C:\dmd>dmd overlord.d
overlord.d(8): function overlord.printValue called with argument types:
(char[14])
matches both:
overlord.printValue(char[])
and:
overlord.printValue(char*)

C:\dmd>

Thanks in advance for your reply,
David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d8991r$18gi$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote in message news:d88dou$961$3@digitaldaemon.com...
> > AAIIIIEEEEEEE !!!!!!
>
> Lol, I take it that's a "no" ;)

I prefer to say "no" to such things unless there is a demonstrable need for it and no easy alternative. Kris was able to demonstrate that for inner classes, so in they went.

"Sean Kelly" <sean@f4.ca> wrote in message news:d89ok7$1pdb$1@digitaldaemon.com...
> Quick question about remove() since I can't test the new release quite
yet.
> Does it return the stored value?  It would be nice if we could do things
like
> this:
>
> int[int] a;
> Objecct[int] b;
> printf( "removed %i\n", a.remove(1) );
> delete b.remove(2);
>
> I grant that the syntax is a bit odd for the delete line, but it saves a
double
> lookup or the need to add a second function for the purpos (erase?).

Currently, it returns a void.

"David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:d89qub$1rno$1@digitaldaemon.com...
> Walter, the following D code now skips on passing in a char[] literal into
a
> function that has both a func(in char[]) and a func(in char *) defined. Is
this
> a new change in D's behavior in handling string literals? Or is this a side-effect / error from the current v0.126 changes?
>
> # // OverLord.d
> # private import std.stdio;
> #
> # int main()
> # {
> #     char[] s = "char[] var";
> #     //printValue(s);  // Works fine.
> #     printValue("char[] literal"); //Now a problem without a cast(char[])
> #
> #     return 0;
> # }
> #
> # void printValue( in char[] s)
> # {
> #     writefln("printValue(in char[]) called, value=%s", s);
> # }
> #
> # void printValue( in char* s)
> # {
> #     writefln("printValue(in char*) called, value=%s", s);
> # }
>
> Output:
> --------
> C:\dmd>dmd overlord.d
> overlord.d(8): function overlord.printValue called with argument types:
> (char[14])
> matches both:
> overlord.printValue(char[])
> and:
> overlord.printValue(char*)

It's intentional, as a string literal is implicitly convertible to either char[] or char*.

On Thu, 9 Jun 2005 14:37:27 +0000 (UTC), Sean Kelly wrote:

> In article <19gr67kb4q1fw.vwbenzrtgmvv$.dlg@40tude.net>, Derek Parnell says...
>>
>>> And because D is pre-1.0, there's little reason to move slowly with changes.
>>
>>Okay, so along comes 1.01 with a new feature. How long should I wait for all the other compilers I want to support to catch up? What if some of those never catch up but are still in use. Borland C v5.5 has lots of adherents.
> 
> True enough.  But should the development of a language be halted for the sake of backwards compatibility?

Of course not.

>  Or do you have a suggestion for how this could be
> resolved another way.  I'm drawing a blank.

Me too. This is a storm in a teacup. An external macro tool is the only reasonable course of action to solve this problem. That's the approach I'll be taking.

-- 
Derek Parnell
Melbourne, Australia
10/06/2005 7:02:33 AM

"Anders F Björklund" <afb@algonet.se> wrote in message news:d8793u$26v2$1@digitaldaemon.com...
> I've been wondering whether it would be worthwhile to
> add something to flag which language version is needed ?
>
> Like it's done in Perl:
> "require v5.6.1;"
> (sure there are others)
>
> Maybe a pragma or something would do the trick in D code ? The idea is to forward : "this code needs DMD >= 0.126".

I'd rather do such things by adding version identifiers for specific features. One reason is my experience with such sequence numbers in the C++ world - they are fairly useless - but predefined macros for specific features works out rather well.

"Derek Parnell" <derek@psych.ward> wrote in message news:15iyeaoc4m2un$.k32eg0afi011.dlg@40tude.net...
> Personally I don't think there is a solution, so I'm resigned to using
some
> other tool to develop with from now on. If someone comes up with a great way of achieving the 'grand' aim of only maintaining one set of source files per application, just let us know. Currently, D alone is not enough; it falls short of ever being able to do this, unlike C and C++. In short,
I
> need an additional tool so I can reduce my development costs.

The C and C++ preprocessor cannot do this in the *general* case. The reason is because the preprocessor works on preprocessor tokens, not on text. If any new tokens were added, then the older preprocessors are obligated to fail, even on the false conditionals.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d86f8l$1e66$1@digitaldaemon.com...
> Walter wrote:
> > Added inner classes.
> >
> > http://www.digitalmars.com/d/changelog.html
>
> Could we please at least have an answer about these?
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3173

The problem is I haven't spent the time thinking about those yet. Other stuff always intrudes.