www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.116 release

reply "Walter" <newshound digitalmars.com> writes:
I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.

http://www.digitalmars.com/d/changelog.html
Mar 07 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Walter, could you shed more light on this:

<cite>
If a module statement name is used with a package prefix, as in:
         import foo.bar;
then bar is not in scope, one must use foo.bar.
</cite>

???

Is this mean that if

import std.string;

then one must use fully qualified
std.string.memcpy name?

Thanks in advance,

Andrew.









"Walter" <newshound digitalmars.com> wrote in message 
news:d0irlm$o0s$1 digitaldaemon.com...

 I'm not too sure about $, __FILE__ or __LINE__. There might be a better 
 way.

 http://www.digitalmars.com/d/changelog.html
Mar 07 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d0is5v$ofv$1 digitaldaemon.com...

 Walter, could you shed more light on this:

 <cite>
 If a module statement name is used with a package prefix, as in:
          import foo.bar;
 then bar is not in scope, one must use foo.bar.
 </cite>

 ???

 Is this mean that if

 import std.string;

 then one must use fully qualified
 std.string.memcpy name?


That's right, but it only applies to the code within std\string.d. The
circumstance happens rarely that one would qualify a name within the module
itself.
Mar 07 2005
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0isrh$p4t$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d0is5v$ofv$1 digitaldaemon.com...

 Walter, could you shed more light on this:

 <cite>
 If a module statement name is used with a package prefix, as in:
          import foo.bar;
 then bar is not in scope, one must use foo.bar.
 </cite>

 ???

 Is this mean that if

 import std.string;

 then one must use fully qualified
 std.string.memcpy name?


 That's right, but it only applies to the code within std\string.d. The
 circumstance happens rarely that one would qualify a name within the 
 module
 itself.


Not so. Yesterday I defined toString() for three enums in std.openrj, 
and then needed to qualify each and every use with std.openrj because 
they were inside the DatabaseException class. This is intensely 
irritating (though I do not claim it as significant for that reason).

On this point - i.e. the notion of generalised/attribute-based coding, 
shims, etc. - I think it's a serious mistake to have instance methods 
have the same name as the shims, i.e. X.toString(), toString(int). It 
reduces the scope for generalised programming markedly. I had started to 
do distinct shims in DTL, i.e. to_string(), and will likely pursue this, 
despite its probable confusion factor, as I don't see any alternative. 
Shims are way too powerful to give away ....
Mar 07 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Walter, beg my pardon but still unclear....

<cite>
If a module statement name is used with a package prefix, as in:
 	import foo.bar;
</cite>

Shall it be

If a module statement name is used with a package prefix, as in:
  module foo.bar;

instead?

Thanks,

Andrew.


"Walter" <newshound digitalmars.com> wrote in message 
news:d0isrh$p4t$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d0is5v$ofv$1 digitaldaemon.com...

 Walter, could you shed more light on this:

 <cite>
 If a module statement name is used with a package prefix, as in:
          import foo.bar;
 then bar is not in scope, one must use foo.bar.
 </cite>

 ???

 Is this mean that if

 import std.string;

 then one must use fully qualified
 std.string.memcpy name?


 That's right, but it only applies to the code within std\string.d. The
 circumstance happens rarely that one would qualify a name within the 
 module
 itself.
Mar 07 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d0itsj$q7v$1 digitaldaemon.com...

 Walter, beg my pardon but still unclear....


------------ old way, doesn't work anymore ------------------

module foo.bar;

void test() { }

void func()
{
    bar.test();
}

------------- new way ------------------

module foo.bar;

void test() { }

void func()
{
    foo.bar.test();
}

------------------------------------------
Mar 07 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
I see now. Thanks a lot, Walter, for comments.

Could you change then

import foo.bar;
to
module foo.bar;

here http://www.digitalmars.com/d/changelog.html#new0116 ?

Andrew.



"Walter" <newshound digitalmars.com> wrote in message 
news:d0iuk9$r4j$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d0itsj$q7v$1 digitaldaemon.com...

 Walter, beg my pardon but still unclear....


 ------------ old way, doesn't work anymore ------------------

 module foo.bar;

 void test() { }

 void func()
 {
    bar.test();
 }

 ------------- new way ------------------

 module foo.bar;

 void test() { }

 void func()
 {
    foo.bar.test();
 }

 ------------------------------------------
Mar 07 2005
parent "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d0iur7$rf4$1 digitaldaemon.com...

 I see now. Thanks a lot, Walter, for comments.

 Could you change then

 import foo.bar;
 to
 module foo.bar;

 here http://www.digitalmars.com/d/changelog.html#new0116 ?


Right. oops!
Mar 07 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0iuk9$r4j$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d0itsj$q7v$1 digitaldaemon.com...

 Walter, beg my pardon but still unclear....


 ------------ old way, doesn't work anymore ------------------

 module foo.bar;

 void test() { }

 void func()
 {
    bar.test();
 }

 ------------- new way ------------------

 module foo.bar;

 void test() { }

 void func()
 {
    foo.bar.test();
 }

 ------------------------------------------


That's at least a lot more sensible.

Tell me, the rusty old twit, can alias work to disambiguate same-named 
functions from multiple modules?
Mar 07 2005
parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0iv6b$rp8$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d0iuk9$r4j$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d0itsj$q7v$1 digitaldaemon.com...

 Walter, beg my pardon but still unclear....


 ------------ old way, doesn't work anymore ------------------

 module foo.bar;

 void test() { }

 void func()
 {
    bar.test();
 }

 ------------- new way ------------------

 module foo.bar;

 void test() { }

 void func()
 {
    foo.bar.test();
 }

 ------------------------------------------


 That's at least a lot more sensible.


What happened was the old way was done before there were packages. I'd
overlooked it until now.



 Tell me, the rusty old twit, can alias work to disambiguate same-named
 functions from multiple modules?


Why not just put the module name in front of it to disambiguate them? That's
how it's supposed to work.
Mar 07 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d0iuk9$r4j$1 digitaldaemon.com>, Walter says...

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d0itsj$q7v$1 digitaldaemon.com...

 Walter, beg my pardon but still unclear....


------------ old way, doesn't work anymore ------------------

module foo.bar;

void test() { }

void func()
{
    bar.test();
}

------------- new way ------------------

module foo.bar;

void test() { }

void func()
{
    foo.bar.test();
}

------------------------------------------



Thank you for the clarification, Walter.  I was scratching my head pretty hard
from your description in the change log.

So I gather that we're supposed to use aliases to get the old behavior, if
that's what we want?

- EricAnderton at yahoo
Mar 07 2005
parent "Walter" <newshound digitalmars.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message
news:d0ivr5$sh5$1 digitaldaemon.com...

 So I gather that we're supposed to use aliases to get the old behavior, if
 that's what we want?


Yes, you could use an alias.
Mar 07 2005
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, so 
thanks for at least giving it a try.  I'm sure we'll let you know what 
we think.

Let me preface myself by saying that I haven't been following the $ or 
__FILE__ discussion (we've got waaay too much going on on this NG 
nowadays) so I aplogize if I'm stepping on anyone's toes.

As for $, __FILE__, and __LINE__...

a meta-keyword...  Then we replace length with $length, __FILE__ with 
$file, ect... All other valid identifiers prefixed with $ should be 
illegal...  This way, when one wants to add features such as these, it 
will not break existing code, and will not necessitate additional 
keywords. Perhaps there are even more uses for these "meta-keywords" as 
well.

Thoughts?

John Demme

Walter wrote:

 I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
 
 http://www.digitalmars.com/d/changelog.html
Mar 07 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
All other valid identifiers prefixed with $ should be

 illegal...  This way, when one wants to add features such as these, it 
 will not break existing code, and will not necessitate additional 
 keywords. Perhaps there are even more uses for these "meta-keywords" as 
 well.


Totally agree.

More candidates on this:

_arguments    ->$arguments
_argptr -> $argptr

Andrew.




"John Demme" <me teqdruid.com> wrote in message 
news:d0itb3$pid$1 digitaldaemon.com...

 Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, so 
 thanks for at least giving it a try.  I'm sure we'll let you know what we 
 think.

 Let me preface myself by saying that I haven't been following the $ or 
 __FILE__ discussion (we've got waaay too much going on on this NG 
 nowadays) so I aplogize if I'm stepping on anyone's toes.

 As for $, __FILE__, and __LINE__...

 meta-keyword...  Then we replace length with $length, __FILE__ with $file, 
 ect... All other valid identifiers prefixed with $ should be illegal... 
 This way, when one wants to add features such as these, it will not break 
 existing code, and will not necessitate additional keywords. Perhaps there 
 are even more uses for these "meta-keywords" as well.

 Thoughts?

 John Demme

 Walter wrote:

 I'm not too sure about $, __FILE__ or __LINE__. There might be a better 
 way.

 http://www.digitalmars.com/d/changelog.html
Mar 07 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:d0itb3$pid$1 digitaldaemon.com...

 Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, 
 so thanks for at least giving it a try.  I'm sure we'll let you know 
 what we think.

 Let me preface myself by saying that I haven't been following the $ or 
 __FILE__ discussion (we've got waaay too much going on on this NG 
 nowadays) so I aplogize if I'm stepping on anyone's toes.

 As for $, __FILE__, and __LINE__...

 identifier> a meta-keyword...  Then we replace length with $length, 
 __FILE__ with $file, ect... All other valid identifiers prefixed with 
 $ should be illegal...  This way, when one wants to add features such 
 as these, it will not break existing code, and will not necessitate 
 additional keywords. Perhaps there are even more uses for these 
 "meta-keywords" as well.

 Thoughts?


Don't like it.

First: $ as a prefix may be getting a far more important and central 
role in the language.

Second: __FILE__ and __LINE__ are damn ugly, and that's a good thing. 
Making them less so might incline people to over/ab-use

Third: __FILE__ and __LINE__ are standard parts of other languages, and 
widely recognised by most/all programmers.
Mar 07 2005
parent reply John Demme <me teqdruid.com> writes:
Matthew wrote:

 "John Demme" <me teqdruid.com> wrote in message 
 news:d0itb3$pid$1 digitaldaemon.com...
 

Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, 
so thanks for at least giving it a try.  I'm sure we'll let you know 
what we think.

Let me preface myself by saying that I haven't been following the $ or 
__FILE__ discussion (we've got waaay too much going on on this NG 
nowadays) so I aplogize if I'm stepping on anyone's toes.

As for $, __FILE__, and __LINE__...

identifier> a meta-keyword...  Then we replace length with $length, 
__FILE__ with $file, ect... All other valid identifiers prefixed with 
$ should be illegal...  This way, when one wants to add features such 
as these, it will not break existing code, and will not necessitate 
additional keywords. Perhaps there are even more uses for these 
"meta-keywords" as well.

Thoughts?


 
 
 Don't like it.
 
 First: $ as a prefix may be getting a far more important and central 
 role in the language.


OK... show me what it is.  There are a few good symbols one could use: 


Also, $arguments, and $argptr, are good for this.  I'm sure they'll be 
more that might be appropriate.  I (obviously) like the idea of being 
able to add small features to the language without breaking code.  This 
means that we'd be able to get convient features between 1.0 and 2.0.


 
 Second: __FILE__ and __LINE__ are damn ugly, and that's a good thing. 
 Making them less so might incline people to over/ab-use
 
 Third: __FILE__ and __LINE__ are standard parts of other languages, and 
 widely recognised by most/all programmers. 


OK... how about $__FILE__ and $__LINE__? they're ugly now :)  Seriously, 
I don't buy it.  If a programmer's going to abuse something, then it 
going to be abused.  If a programmer don't know what abuse is, I'm not 
certain (s)he's gonna know what code beauty is either.  But maybe I'm 
outta my gourd.

John
Mar 07 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:d0iujc$r3o$1 digitaldaemon.com...

 Matthew wrote:

 "John Demme" <me teqdruid.com> wrote in message 
 news:d0itb3$pid$1 digitaldaemon.com...


Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, 
so thanks for at least giving it a try.  I'm sure we'll let you know 
what we think.

Let me preface myself by saying that I haven't been following the $ 
or __FILE__ discussion (we've got waaay too much going on on this NG 
nowadays) so I aplogize if I'm stepping on anyone's toes.

As for $, __FILE__, and __LINE__...

identifier> a meta-keyword...  Then we replace length with $length, 
__FILE__ with $file, ect... All other valid identifiers prefixed with 
$ should be illegal...  This way, when one wants to add features such 
as these, it will not break existing code, and will not necessitate 
additional keywords. Perhaps there are even more uses for these 
"meta-keywords" as well.

Thoughts?



 Don't like it.

 First: $ as a prefix may be getting a far more important and central 
 role in the language.


 OK... show me what it is.  There are a few good symbols one could use: 

 do.

 Also, $arguments, and $argptr, are good for this.  I'm sure they'll be 
 more that might be appropriate.  I (obviously) like the idea of being 
 able to add small features to the language without breaking code. 
 This means that we'd be able to get convient features between 1.0 and 
 2.0.


Well, I hate the _arguments stuff. Underscores are for
    - compiler extensions. This is expressely against the D philosphy, 
and DMD should never have them
    - irrepairable mistakes. D shouldn't have any of these prior to 1.0. 
(Although it's trying ...)

I don't know whether they can be made to fit the $xyz model, but my gut 
says they can (and should)


 Second: __FILE__ and __LINE__ are damn ugly, and that's a good thing. 
 Making them less so might incline people to over/ab-use

 Third: __FILE__ and __LINE__ are standard parts of other languages, 
 and widely recognised by most/all programmers.


 OK... how about $__FILE__ and $__LINE__? they're ugly now :) 
 Seriously, I don't buy it.  If a programmer's going to abuse 
 something, then it going to be abused.  If a programmer don't know 
 what abuse is, I'm not certain (s)he's gonna know what code beauty is 
 either.  But maybe I'm outta my gourd.


Well, there's no distinguishment between things that are part of the 
language proper, and things which are more compile-time 'facilities'.

$length, assuming that particular syntax is the goer, would be a 
regularly used facility. It's 'normal' code.

__DATE__, on the other hand, is a symbol that the compiler generates on 
our behalf, and would not anything but 'normal'. Nor would it 
manipulable. It's a context-dependent constant, I guess.

The two things are different, IMO, and should be represented as such.

In any case, you've not addressed the consistency issue. Even 
syntactically 'weird' languages such as Ruby still use __FILE__.

(Python uses __file__, but then source files are an 'active' part of 
Python, whereas in C/C++/D/Java/.NET they are the stuff that happens 
before the code becomes code.)
Mar 07 2005
parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> skrev i en meddelelse 
news:d0iv6c$rp8$2 digitaldaemon.com...

 $length, assuming that particular syntax is the goer, would be a regularly 
 used facility. It's 'normal' code.


And people coming from BASIC would think that it is a string :-)

Regards,
Martin
Mar 08 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0irlm$o0s$1 digitaldaemon.com...

 I'm not too sure about $, __FILE__ or __LINE__. There might be a 
 better way.

 http://www.digitalmars.com/d/changelog.html


He he. I'm now inclining towards a more general approach to context 
dependency, following the $length, $count, etc. mentioned (by 
??forgotten??; sorry) the other day.

Simply put, $ would mean 'within the context of the innermost entity', 
so:


    int[]    a = . . .

    if( 0 != a.length &&
        a[$length - 1] == 10)
    {
           ...

Thus $ is not 'wasted' on array length, and neither $len nor $length 
(nor anything else) are defined as some special funky kinds of keywords. 
Rather, $X means that X is relative. Like a deeper/funkier with.

I'll leave it to faster/sharper minds to come up with all the wild 
ramifications of this ...


:-)
Mar 07 2005
next sibling parent reply John Demme <me teqdruid.com> writes:
Matthew wrote:

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d0irlm$o0s$1 digitaldaemon.com...
 

I'm not too sure about $, __FILE__ or __LINE__. There might be a 
better way.

http://www.digitalmars.com/d/changelog.html


 
 
 He he. I'm now inclining towards a more general approach to context 
 dependency, following the $length, $count, etc. mentioned (by 
 ??forgotten??; sorry) the other day.
 
 Simply put, $ would mean 'within the context of the innermost entity', 
 so:


I don't think that's the best definition, as I think that that's the 
default. The way I read it, these are equivalent:
array[4..length];
and
array[4..$length];

It doesn't say anything about certain identifiers only existing after a $.


 
 
     int[]    a = . . .
 
     if( 0 != a.length &&
         a[$length - 1] == 10)
     {
            ...
 


Looking at the example, it seems to me what you want is that 
$<identifier> is an alias for the property of the last variable in the 
chain.  Example:
a.b.c($something);
the $something returns c.something if it exists, then b.something if it 
exists, then a.something if it exists, or doesn't compile... or am I 
looking too far into this?

John Demme
Mar 07 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:d0iu6v$qk7$1 digitaldaemon.com...

 Matthew wrote:

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d0irlm$o0s$1 digitaldaemon.com...


I'm not too sure about $, __FILE__ or __LINE__. There might be a 
better way.

http://www.digitalmars.com/d/changelog.html



 He he. I'm now inclining towards a more general approach to context 
 dependency, following the $length, $count, etc. mentioned (by 
 ??forgotten??; sorry) the other day.

 Simply put, $ would mean 'within the context of the innermost 
 entity', so:


 I don't think that's the best definition,


That's why I put it in the quotes. I leave it to those more expert in 
programming linguistics to define the term. They'll be along shortly, 
you can be sure ...


 as I think that that's the default. The way I read it, these are 
 equivalent:
 array[4..length];
 and
 array[4..$length];

 It doesn't say anything about certain identifiers only existing after 
 a $.


No. I mean we dispense with the evil first form, and require anyone not 
wanting to write

    array[4 .. array.length]

to write

    array[4 .. $length]


     int[]    a = . . .

     if( 0 != a.length &&
         a[$length - 1] == 10)
     {
            ...


 Looking at the example, it seems to me what you want is that 
 $<identifier> is an alias for the property of the last variable in the 
 chain.  Example:
 a.b.c($something);
 the $something returns c.something if it exists, then b.something if 
 it exists, then a.something if it exists, or doesn't compile... or am 
 I looking too far into this?


No, you're not. I'm hoping very much all you smart cookies will look 
deeply into this idea, and solve all the riddles I've not even bothered 
to think about yet. :-)

I don't know if the definition would be 'last variable in the chain'; 
that's why I said 'within the context of the innermost entity'.

If others could chime in with different use cases, i.e. things other 
than array length, then I think we might be able to come up with 
something rather groovy.
Mar 07 2005
prev sibling next sibling parent xs0 <xs0 xs0.com> writes:
 Simply put, $ would mean 'within the context of the innermost entity', 
 so:


Isn't the context of the innermost entity the default? :)
Mar 07 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Hmmmm....

Can we just use "dot" for that?

if( 0 != a.length && a[ .length - 1] == 10)

[]  brackets establish context (pretty much as 'with')
a[.length-1] or
a[.last]

means as you said length of innermost array

.arguments[] vector may also work.









"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d0itm4$q26$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d0irlm$o0s$1 digitaldaemon.com...

 I'm not too sure about $, __FILE__ or __LINE__. There might be a better 
 way.

 http://www.digitalmars.com/d/changelog.html


 He he. I'm now inclining towards a more general approach to context 
 dependency, following the $length, $count, etc. mentioned (by 
 ??forgotten??; sorry) the other day.

 Simply put, $ would mean 'within the context of the innermost entity', so:


    int[]    a = . . .

    if( 0 != a.length &&
        a[$length - 1] == 10)
    {
           ...

 Thus $ is not 'wasted' on array length, and neither $len nor $length (nor 
 anything else) are defined as some special funky kinds of keywords. 
 Rather, $X means that X is relative. Like a deeper/funkier with.

 I'll leave it to faster/sharper minds to come up with all the wild 
 ramifications of this ...


 :-)
Mar 07 2005
next sibling parent zwang <nehzgnaw gmail.com> writes:
Andrew Fedoniouk wrote:

 Hmmmm....
 
 Can we just use "dot" for that?
 
 if( 0 != a.length && a[ .length - 1] == 10)
 
 []  brackets establish context (pretty much as 'with')
 a[.length-1] or
 a[.last]
 
 means as you said length of innermost array
 
 .arguments[] vector may also work.
 


.length should refer to the length variable defined in the outer scope.
Mar 07 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
    1..length

Is that a range between 1 and a variable length, or between 1. and 
.length?

I suspect the latter won't compile, but I'm sure you get the point

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d0iuko$r4p$1 digitaldaemon.com...

 Hmmmm....

 Can we just use "dot" for that?

 if( 0 != a.length && a[ .length - 1] == 10)

 []  brackets establish context (pretty much as 'with')
 a[.length-1] or
 a[.last]

 means as you said length of innermost array

 .arguments[] vector may also work.









 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d0itm4$q26$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d0irlm$o0s$1 digitaldaemon.com...

 I'm not too sure about $, __FILE__ or __LINE__. There might be a 
 better way.

 http://www.digitalmars.com/d/changelog.html


 He he. I'm now inclining towards a more general approach to context 
 dependency, following the $length, $count, etc. mentioned (by 
 ??forgotten??; sorry) the other day.

 Simply put, $ would mean 'within the context of the innermost 
 entity', so:


    int[]    a = . . .

    if( 0 != a.length &&
        a[$length - 1] == 10)
    {
           ...

 Thus $ is not 'wasted' on array length, and neither $len nor $length 
 (nor anything else) are defined as some special funky kinds of 
 keywords. Rather, $X means that X is relative. Like a deeper/funkier 
 with.

 I'll leave it to faster/sharper minds to come up with all the wild 
 ramifications of this ...


 :-)
Mar 07 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I suspect the latter won't compile, but I'm sure you get the point


Sure :)
Mar 07 2005
prev sibling parent "Nick Sabalausky" <z a.a> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d0iuko$r4p$1 digitaldaemon.com...

 Hmmmm....

 Can we just use "dot" for that?

 if( 0 != a.length && a[ .length - 1] == 10)

 []  brackets establish context (pretty much as 'with')
 a[.length-1] or
 a[.last]

 means as you said length of innermost array

 .arguments[] vector may also work.


Using "dot" like that is already the global scope resolution operator.



 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d0itm4$q26$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d0irlm$o0s$1 digitaldaemon.com...

 I'm not too sure about $, __FILE__ or __LINE__. There might be a better 
 way.

 http://www.digitalmars.com/d/changelog.html


 He he. I'm now inclining towards a more general approach to context 
 dependency, following the $length, $count, etc. mentioned (by 
 ??forgotten??; sorry) the other day.

 Simply put, $ would mean 'within the context of the innermost entity', 
 so:


    int[]    a = . . .

    if( 0 != a.length &&
        a[$length - 1] == 10)
    {
           ...

 Thus $ is not 'wasted' on array length, and neither $len nor $length (nor 
 anything else) are defined as some special funky kinds of keywords. 
 Rather, $X means that X is relative. Like a deeper/funkier with.

 I'll leave it to faster/sharper minds to come up with all the wild 
 ramifications of this ...


 :-)
Mar 09 2005
prev sibling next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 Thus $ is not 'wasted' on array length, and neither $len nor $length (nor 
 anything else) are defined as some special funky kinds of keywords. 
 Rather, $X means that X is relative. Like a deeper/funkier with.

 I'll leave it to faster/sharper minds to come up with all the wild 
 ramifications of this ...


you mean like what $EX would return? hmm...
Mar 07 2005
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
Nice idea, but any such general approach will not scale up to 
multidimensional arrays. A $ or a keyword can always be given the 
meaning "length of the appropriate dimension". It will be hard to 
capture this with any general "with"-like approach.


Matthew schrieb:

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d0irlm$o0s$1 digitaldaemon.com...
 

I'm not too sure about $, __FILE__ or __LINE__. There might be a 
better way.

http://www.digitalmars.com/d/changelog.html


 
 
 He he. I'm now inclining towards a more general approach to context 
 dependency, following the $length, $count, etc. mentioned (by 
 ??forgotten??; sorry) the other day.
 
 Simply put, $ would mean 'within the context of the innermost entity', 
 so:
 
 
     int[]    a = . . .
 
     if( 0 != a.length &&
         a[$length - 1] == 10)
     {
            ...
 
 Thus $ is not 'wasted' on array length, and neither $len nor $length 
 (nor anything else) are defined as some special funky kinds of keywords. 
 Rather, $X means that X is relative. Like a deeper/funkier with.
 
 I'll leave it to faster/sharper minds to come up with all the wild 
 ramifications of this ...
 
 
 :-)
Mar 08 2005
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
Warning messages with Mango:









the above produces a "statement not reachable" message for the null return. I
think you'd agree that the statement most certainly should be reachable?




The warning "implicit conversion of type long to int can cause loss of data"
caught a Mango v1.2 change when formatting a cookie-age ~ it should have stated
Long.format(tmp, maxAge) instead. I borked that when updating from a generic
xtoi() routine that accepted a long. Thank goodness for warnings!







Another bogus "statement is unreachable" message. Variable 'i' is an int, so it
can be less than zero.






Yet another. The unreachable-code warning seems to be broken?








And another.

I have to keep commenting-out code to get the compiler to move on, and I know
this unreachable-code thing is gonna' produce a lot more messages (at this
rate). Can you fix this please, and then I'll continue?

Thanks;
Mar 07 2005
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Kris wrote:

 Warning messages with Mango:
 
 






 
 the above produces a "statement not reachable" message for the null return. I
 think you'd agree that the statement most certainly should be reachable?
 


humm... i'm not 100% but i think the reason it is not reachable is 
because if the 'if statement' is true then the 'return null' will be the 
'dead code'

simple fix would be...

if (name in dictionary)
    return dictionary[name];
else
    return null;

unless i'm just not understanding your point... :-/
Mar 07 2005
parent Kris <Kris_member pathlink.com> writes:
In article <d0j5nd$13fd$1 digitaldaemon.com>, clayasaurus says...

Kris wrote:

 Warning messages with Mango:
 
 






 
 the above produces a "statement not reachable" message for the null return. I
 think you'd agree that the statement most certainly should be reachable?
 


humm... i'm not 100% but i think the reason it is not reachable is 
because if the 'if statement' is true then the 'return null' will be the 
'dead code'

simple fix would be...

if (name in dictionary)
    return dictionary[name];
else
    return null;

unless i'm just not understanding your point... :-/


It would only be dead-code if it were in a combined block with the other return
(would be vaguely amusing if the 'else' actually did make a difference :-)  

Nay ~ I think it's just a case of a bug in the message-production instead.
There's plenty other false-positives to back that assertion.
Mar 07 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Kris" <Kris_member pathlink.com> wrote in message 
news:d0j2gi$vfp$1 digitaldaemon.com...

 Warning messages with Mango:









 the above produces a "statement not reachable" message for the null 
 return. I
 think you'd agree that the statement most certainly should be 
 reachable?


Could be some hat-eating here ...




 The warning "implicit conversion of type long to int can cause loss of 
 data"
 caught a Mango v1.2 change when formatting a cookie-age ~ it should 
 have stated
 Long.format(tmp, maxAge) instead. I borked that when updating from a 
 generic
 xtoi() routine that accepted a long. Thank goodness for warnings!


:-)
Mar 07 2005
parent Derek Parnell <derek psych.ward> writes:
On Tue, 8 Mar 2005 14:07:25 +1100, Matthew wrote:


 "Kris" <Kris_member pathlink.com> wrote in message 
 news:d0j2gi$vfp$1 digitaldaemon.com...

 Warning messages with Mango:









 the above produces a "statement not reachable" message for the null 
 return. I
 think you'd agree that the statement most certainly should be 
 reachable?


 
 Could be some hat-eating here ...


Maybe, but I'm starting to think that Walter's idea of unreachable code is
a lot different than mine. I'm getting a lot of this type of thing ...

void search() {
    char[] [] lFiles;
    FileDateTime lCurFileTime;
    bool lCanUse;
    int lTextPos = 0;
    
    if(mHasBeenSearched) {
        return;
    }
    
    if(mVerboseMode) {   //<<<<<<<< UNREACHABLE? I don't think so!
      writefln("Scanning %s", mFileName);
    }

[snipped a whole mess of code]
        
        mHasBeenSearched = true;
}
    

 



 The warning "implicit conversion of type long to int can cause loss of 
 data"
 caught a Mango v1.2 change when formatting a cookie-age ~ it should 
 have stated
 Long.format(tmp, maxAge) instead. I borked that when updating from a 
 generic
 xtoi() routine that accepted a long. Thank goodness for warnings!


 
 :-)


This caught a mistake by me too. I had ...

   int x = atoi(text);

Silly me thinking that 'atoi' meant ASCII text to int. It actually returns
a long!

Another time I had to change ...

    bool IsActive( char[] pID )
    {
      return ( (pID in vActiveVersions) != null);
    }

to this ...

    bool IsActive( char[] pID )
    {
    return (pID in vActiveVersions) !== null ? true : false ;
    }

which is actually better code.

-- 
Derek
Melbourne, Australia
8/03/2005 2:46:53 PM
Mar 07 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Kris" <Kris_member pathlink.com> wrote in message
news:d0j2gi$vfp$1 digitaldaemon.com...

 Warning messages with Mango:









 the above produces a "statement not reachable" message for the null


return. I

 think you'd agree that the statement most certainly should be reachable?


Yes. That looks like a bug. I'll fix it.
Mar 07 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 7 Mar 2005 19:49:56 -0800, Walter wrote:


 "Kris" <Kris_member pathlink.com> wrote in message
 news:d0j2gi$vfp$1 digitaldaemon.com...

 Warning messages with Mango:









 the above produces a "statement not reachable" message for the null


 return. I

 think you'd agree that the statement most certainly should be reachable?


 
 Yes. That looks like a bug. I'll fix it.


Great! I just had about 50 of these to get around.

-- 
Derek
Melbourne, Australia
8/03/2005 3:09:33 PM
Mar 07 2005
prev sibling parent Kris <Kris_member pathlink.com> writes:
Thanks. 

Right now, the compiler halts after emiting a few warnings ... can you perhaps
make it continue until it hits some errors (or runs out of files), please?



In article <d0j7qe$15t6$1 digitaldaemon.com>, Walter says...

"Kris" <Kris_member pathlink.com> wrote in message
news:d0j2gi$vfp$1 digitaldaemon.com...

 Warning messages with Mango:









 the above produces a "statement not reachable" message for the null


return. I

 think you'd agree that the statement most certainly should be reachable?


Yes. That looks like a bug. I'll fix it.
Mar 07 2005
prev sibling next sibling parent reply David Medlock <amedlock nospam.com> writes:
Walter wrote:

 I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
 
 http://www.digitalmars.com/d/changelog.html
 


Why not just make with() apply to arrays as well?

Cleaner, imo.

with(a) x[0..length] = a[0..length];
Mar 07 2005
next sibling parent John Demme <me teqdruid.com> writes:
David Medlock wrote:

 Walter wrote:
 

 I'm not too sure about $, __FILE__ or __LINE__. There might be a 
 better way.

 http://www.digitalmars.com/d/changelog.html


 
 Why not just make with() apply to arrays as well?
 
 Cleaner, imo.
 
 with(a) x[0..length] = a[0..length];
 


Ewwie... Confusing... the first time I looked at that I thought, "but 
what if x and a are different sizes?" Then I re-read it.
Mar 07 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 Why not just make with() apply to arrays as well?

 Cleaner, imo.

 with(a) x[0..length] = a[0..length];


What about where you've got more than array involved in the statement?
Mar 07 2005
parent reply David Medlock <amedlock nospam.com> writes:
Matthew wrote:


Why not just make with() apply to arrays as well?

Cleaner, imo.

with(a) x[0..length] = a[0..length];


 
 
 What about where you've got more than array involved in the statement?
 
 
 


with(a) x[0..length] = a[0..length];
^^^^^^^
Mar 07 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"David Medlock" <amedlock nospam.com> wrote in message 
news:d0j92e$1706$1 digitaldaemon.com...

 Matthew wrote:


Why not just make with() apply to arrays as well?

Cleaner, imo.

with(a) x[0..length] = a[0..length];



 What about where you've got more than array involved in the 
 statement?


 with(a) x[0..length] = a[0..length];
 ^^^^^^^


Sorry, my mistake.

So what does the above code do? It'd confuse the shit out of me even 
were it legal.
Mar 07 2005
parent David Medlock <amedlock nospam.com> writes:
Matthew wrote:


 "David Medlock" <amedlock nospam.com> wrote in message 
 news:d0j92e$1706$1 digitaldaemon.com...
 

Matthew wrote:



Why not just make with() apply to arrays as well?

Cleaner, imo.

with(a) x[0..length] = a[0..length];



What about where you've got more than array involved in the 
statement?


with(a) x[0..length] = a[0..length];
^^^^^^^


 
 
 Sorry, my mistake.
 
 So what does the above code do? It'd confuse the shit out of me even 
 were it legal.
 
 
 


With broadens a search for scoped variables. So when the compiler tries 
to figure out what length is, it checks with block, then local scope, etc.

Its standard in pascal, although I dont know why walter only allows one 
item in there.  Its a nice timesaver and underrated, imo.
Mar 07 2005
prev sibling next sibling parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <d0irlm$o0s$1 digitaldaemon.com>, Walter says...

I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.

http://www.digitalmars.com/d/changelog.html


I like $. Code looks very readable to me.  :-)
Thanks!

Ugis
Mar 08 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
U.Baumanis wrote:


I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.

http://www.digitalmars.com/d/changelog.html


 
 I like $. Code looks very readable to me.  :-)


Good for writing gnomish programs:

   char[][] phases;
   phases.length = 3;

   phases[0 .. 1] = "Collect underpants";
   phases[1 .. 2];
   phases[2 .. $] = "Profit!";

Totally readable, I agree. :-P
But it does not work in GDC...

And I *still* just don't see what was
wrong with just using phases.length ?

--anders

PS. It's from Episode 217.
http://www.tvtome.com/tvtome/servlet/GuidePageServlet/showid-344/epid-2446
Mar 08 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 08 Mar 2005 10:03:55 +0100, Anders F Björklund <afb algonet.se>  
wrote:

 And I *still* just don't see what was
 wrong with just using phases.length ?


char[] function() {...}
function()[0..??]  //how to express the length?

really_long_and_complicated_expression_you_dont_want_to_evaluate_twice[0..really_long_and_complicated_expression_you_dont_want_to_ev
luate_twice.length]  
//not so easy to read.

It's really just syntactical sugar, except...

void fn(inout char[] aa) {aa.length = aa.length + 1}
int length;

length = aa.length;
if (fn(aa) && length == 5) {..} //length invalid at this point.

(of course the soln is to replace length above with aa.length.. except if  
I also replace aa with one of the first two examples)

Regan
Mar 08 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:


 And I *still* just don't see what was
 wrong with just using phases.length ?


 
 char[] function() {...}
 function()[0..??]  //how to express the length?
 
 really_long_and_complicated_expression_you_dont_want_to_evaluate_twice[0..really_long_and_complicated_expression_you_dont_want_to_ev
luate_twice.length]  
 //not so easy to read.
 
 It's really just syntactical sugar, except...


So just use a temp ? Compiler has to, anyway.

Besides, you can also use [] instead of [0..$] ?

Oh well. When GDC gets it, I'll think about it.

--anders
Mar 08 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 08 Mar 2005 10:35:06 +0100, Anders F Björklund <afb algonet.se>  
wrote:

 Regan Heath wrote:


 And I *still* just don't see what was
 wrong with just using phases.length ?


  char[] function() {...}
 function()[0..??]  //how to express the length?
   
 really_long_and_complicated_expression_you_dont_want_to_evaluate_twice[0..really_long_and_complicated_expression_you_dont_want_to_ev
luate_twice.length]   
 //not so easy to read.
  It's really just syntactical sugar, except...


 So just use a temp ?


That's what I did, in my example:

void fn(inout char[] aa) {aa.length = aa.length + 1}
int length;

length = aa.length;
if (fn(aa) && length == 5) {..} //length invalid at this point.

using a temp could cause a nasty problem. Granted it's probably rare, but  
I think it would be very nasty.


 Compiler has to, anyway.


No, the compiler can access the 'length' method/member/value for the  
object in question.


 Besides, you can also use [] instead of [0..$] ?


This is beside the point.

Regan
Mar 08 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:


  char[] function() {...}
 function()[0..??]  //how to express the length?
   
 really_long_and_complicated_expression_you_dont_want_to_evaluate_twice[0..really_long_and_complicated_expression_you_dont_want_to_ev
luate_twice.length]   
 //not so easy to read.
  It's really just syntactical sugar, except...


 So just use a temp ?


 
 That's what I did, in my example:


No, I meant:

char[] temp = function();

temp = really_long_and_complicated_expression;

temp[0..temp.length];

Like that.


 void fn(inout char[] aa) {aa.length = aa.length + 1}
 int length;
 
 length = aa.length;
 if (fn(aa) && length == 5) {..} //length invalid at this point.
 
 using a temp could cause a nasty problem. Granted it's probably rare, 
 but  I think it would be very nasty.


Nastiest right now is that any "length" variable is sometimes hidden.

But I meant a temp for the array reference, not the length. (see above)


 Compiler has to, anyway.


 
 No, the compiler can access the 'length' method/member/value for the  
 object in question.


That was the temp I meant. (the object)


 Besides, you can also use [] instead of [0..$] ?


 This is beside the point.


It was.

--anders
Mar 08 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 08 Mar 2005 10:44:08 +0100, Anders F Björklund <afb algonet.se>  
wrote:

 Regan Heath wrote:


  char[] function() {...}
 function()[0..??]  //how to express the length?
    
 really_long_and_complicated_expression_you_dont_want_to_evaluate_twice[0..really_long_and_complicated_expression_you_dont_want_to_ev
luate_twice.length]    
 //not so easy to read.
  It's really just syntactical sugar, except...


 So just use a temp ?


  That's what I did, in my example:


 No, I meant:

 char[] temp = function();

 temp = really_long_and_complicated_expression;

 temp[0..temp.length];

 Like that.


Oh, sorry. I see.


 void fn(inout char[] aa) {aa.length = aa.length + 1}
 int length;
  length = aa.length;
 if (fn(aa) && length == 5) {..} //length invalid at this point.
  using a temp could cause a nasty problem. Granted it's probably rare,  
 but  I think it would be very nasty.


 Nastiest right now is that any "length" variable is sometimes hidden.


True, I was assuming that was removed.


 But I meant a temp for the array reference, not the length. (see above)


Yep, gotcha.

Regan
Mar 08 2005
prev sibling parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
Good for writing gnomish programs:

   char[][] phases;
   phases.length = 3;

   phases[0 .. 1] = "Collect underpants";
   phases[1 .. 2];
   phases[2 .. $] = "Profit!";

Totally readable, I agree. :-P
But it does not work in GDC...

And I *still* just don't see what was
wrong with just using phases.length ?

--anders


I like your comment, but cannot help. :-)
Good example BTW, especially "Profit!" part. :-)

Ugis
Mar 08 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
U.Baumanis wrote:


But it does not work in GDC...


 
 I like your comment, but cannot help. :-)


That's OK, it's just that GDC is at
DMD level 110 now and hasn't got all
the new features just yet (but it will)

It's something to be aware of, as it has
been in the past. All D code should state
the minimum compiler version needed to compile.

Or at least the version that it was written with ?

--anders
Mar 08 2005
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
 
 http://www.digitalmars.com/d/changelog.html


"warning - array 'length' hides other 'length' name in outer scope"
...
"The warning can be resolved by:

    1. Renaming the outer length to another name.
    2. Replacing the use of length within the [ ] with a.length.
    3. If length is at global or class scope, and that was the one 
intended to be used, use .length or this.length to disambiguate.

Some proposed language solutions are:

    1. Make the length a special symbol or a keyword instead of an 
implicitly declared variable."

You've just added the $ notation, yet you haven't mentioned it here. 
Simply because it's a trial feature, and the page might end up out of 
date if you decide to get rid of it?

And IMM making length a keyword wouldn't be the Right Thing - we'd lose 
the ability to use this name for a property in container classes.

"Fixed D.bugs/1849"

Excellent!

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 08 2005
prev sibling next sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
I think this is a bug:

//-----------------------------------------------
int bar() { return 0; }
bool foo() { return bar()==0; }
void main() {}
//-----------------------------------------------

warning - test.d(2): implicit conversion of expression (bar == 0) of
type int to bit can cause loss of data

Same happens if bar is instead a variable, but not if it's a constant.

Notice, however, that this doesn't produce any warning:

int foo() { return null?0:1; }

But this does:

bool foo() { return null; }

_______________________
Carlos Santander Bernal
Mar 08 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 I'm not too sure about $


Oh, Christ Almighty.  Coming from a basic background, this is going to look 
confusing.  Strings everywhere.
Mar 08 2005
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Jarrett Billingsley wrote:

I'm not too sure about $


 
 
 Oh, Christ Almighty.  Coming from a basic background, this is going to look 
 confusing.  Strings everywhere. 
 
 


He is indeed. Please don't resort to profanity.
Mar 08 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
We've decided to placate Believers, Agnostics and Atheists on this ng by 
referring to Bob, who may be what/whomever you choose, or your reader 
interprets. ;)

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:d0l3vf$b52$1 digitaldaemon.com...

 I'm not too sure about $


 Oh, Christ Almighty.  Coming from a basic background, this is going to 
 look confusing.  Strings everywhere.
Mar 08 2005
next sibling parent Brad Anderson <brad dsource.dot.org> writes:
Matthew wrote:

 We've decided to placate Believers, Agnostics and Atheists on this ng by 
 referring to Bob, who may be what/whomever you choose, or your reader 
 interprets. ;)
 
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:d0l3vf$b52$1 digitaldaemon.com...
 

I'm not too sure about $


Oh, Christ Almighty.  Coming from a basic background, this is going to 
look confusing.  Strings everywhere.


 
 
 



Bobdamnit!
Mar 08 2005
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 We've decided to placate Believers, Agnostics and Atheists on this ng by 
 referring to Bob, who may be what/whomever you choose, or your reader 
 interprets. ;)


Oh, Bob Almighty then.
Mar 09 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 http://www.digitalmars.com/d/changelog.html


http://www.digitalmars.com/d/changelog.html#new0116


 Bugs Fixed:






http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/983
a.k.a. "OS X bug: universal alpha identifiers"


 Programs with non-ascii identifiers do not
 link, under Mac OS X 10.3 using GDC 0.10...
 
 They use the mangled name as a label for
 the assembler, and then choke on the UTF-8


Great, now I can start using all weirdo names! :-)
http://www.algonet.se/~afb/d/universalalphas/

Well, when GDC catches up with DMD again that is...
(currently gdc 0.10 is at dmd 0.110, feature-wise)

--anders
Mar 08 2005