On Fri, 01 Jan 2010 11:16:00 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
> Well I'm sorry to tell that inout is useless as currently implemented. One important motivating use case was:
>
> inout(char)[] blah(inout(char)[] input) {
>      return input;
> }
>
> void main()
> {
>      blah("xyz");
>      blah("xyz".dup);
> }
>
> That doesn't work at all.

Yeah, I think walter said the inout currently must apply to the entire parameter/return value.  That is a severe limitation I think, but the fact that it parses makes me think it's a simple fix.  It's almost like the type system is working right, but the trigger to convert inout back and forth isn't firing.

> The second motivating case also doesn't work:
>
> class A {
>      A _next;
>      inout A next() inout { return _next; }
> }
>
> void main()
> {
>      auto a = new A;
>      const b = a;
>      auto c = a.next();
>      auto d = b.next();
> }

I found that inout member functions don't work at all.  It's almost as if the compiler ignores the inout designation when doing the inout const match.

>
> There are few, if any, cases where the current inout does help. The good news is that most of the implementation effort has been done so probably making things work will not be very difficult.

Yeah, I just was disappointed that it was listed as implemented.  Half implemented is ok, as long as it will be fixed.

-Steve

On 2009-12-31 13:48:09 -0500, Walter Bright <newshound1@digitalmars.com> said:

> Happy New Year!
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.054.zip
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.038.zip
> 
> Many thanks to the numerous people who contributed to this update.

Thanks.

There's a quite annoying bug on Mac OS X that I've been able to reduce to a very simple test case. Depending on link order, static initializers might not work, resulting in, among other things, a non-functional writeln.

Also when that happens even 'throw' often does not work (execution continues after throw!). It seems linked. This makes 'enforce' non-functional and you get a null dereference when calling writeln instead of an exception.

The workaround seems to be to always link first the module containing 'main'. But it's quite annoying that you can get a segfault with a program as simple as hello world split in two modules. Would it be possible to look at it?

<http://d.puremagic.com/issues/show_bug.cgi?id=3453>


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Moritz Warning wrote:
> On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:
> 
>> bearophile wrote:
>>> grauzone:
>>>> But I have a problem: the compiler is either extremely slow for me, or
>>>> is stuck in an endless loop. All it does is to slowly allocate memory.
>>>> I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation.
>>>> This wasn't the case with dmd 1.053, where it only took 5-10 seconds
>>>> to compile. Can anyone confirm this?
>>> Show the code!
>> I was going to say "but it's hundreds of modules", but then I tried to
>> compile some other big hog of code: Tango.
>>
>> And I found compiling this file hangs:
>> http://dsource.org/projects/tango/browser/trunk/tango/core/tools/
> Demangler.d?rev=5248
>> The exact command line for this was:
>> dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
>> -oftango-core-tools-Demangler-release.o ../tango/core/tools/Demangler.d
>>
>> Again, could anyone confirm this?
>>
>> Anyway, no time for this anymore, it's going to be 2010 soon here.
>>
>>> Bye,
>>> bearophile
> Someone reported the regression already:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=3663

It's caused by the patch for bug 400.

On Fri, 01 Jan 2010 19:31:49 +0100, Don wrote:

> Moritz Warning wrote:
>> On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:
>> 
>>> bearophile wrote:
>>>> grauzone:
>>>>> But I have a problem: the compiler is either extremely slow for me, or is stuck in an endless loop. All it does is to slowly allocate memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile. Can anyone confirm this?
>>>> Show the code!
>>> I was going to say "but it's hundreds of modules", but then I tried to compile some other big hog of code: Tango.
>>>
>>> And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/
>> Demangler.d?rev=5248
>>> The exact command line for this was:
>>> dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
>>> -oftango-core-tools-Demangler-release.o
>>> ../tango/core/tools/Demangler.d
>>>
>>> Again, could anyone confirm this?
>>>
>>> Anyway, no time for this anymore, it's going to be 2010 soon here.
>>>
>>>> Bye,
>>>> bearophile
>> Someone reported the regression already:
>> 
>> http://d.puremagic.com/issues/show_bug.cgi?id=3663
> 
> It's caused by the patch for bug 400.

Thanks, that fixed it.

But now there is another problem/regression:

tango/net/device/Berkeley.d(1065): Error: enum member
tango.net.device.Berkeley.IPv4Address.ADDR_ANY conflicts with enum member
tango.net.device.Berkeley.IPv4Address.ADDR_ANY at tango/net/device/
Berkeley.d(1065)
tango/net/device/Berkeley.d(1066): Error: enum member
tango.net.device.Berkeley.IPv4Address.ADDR_NONE conflicts with enum
member tango.net.device.Berkeley.IPv4Address.ADDR_NONE at tango/net/
device/Berkeley.d(1066)
tango/net/device/Berkeley.d(1067): Error: enum member
tango.net.device.Berkeley.IPv4Address.PORT_ANY conflicts with enum member
tango.net.device.Berkeley.IPv4Address.PORT_ANY at tango/net/device/
Berkeley.d(1067)

On Fri, 01 Jan 2010 22:35:12 +0000, Moritz Warning wrote:

> On Fri, 01 Jan 2010 19:31:49 +0100, Don wrote:
> 
>> Moritz Warning wrote:
>>> On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:
>>> 
>>>> bearophile wrote:
>>>>> grauzone:
>>>>>> But I have a problem: the compiler is either extremely slow for me, or is stuck in an endless loop. All it does is to slowly allocate memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile. Can anyone confirm this?
>>>>> Show the code!
>>>> I was going to say "but it's hundreds of modules", but then I tried to compile some other big hog of code: Tango.
>>>>
>>>> And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/
>>> Demangler.d?rev=5248
>>>> The exact command line for this was:
>>>> dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
>>>> -oftango-core-tools-Demangler-release.o
>>>> ../tango/core/tools/Demangler.d
>>>>
>>>> Again, could anyone confirm this?
>>>>
>>>> Anyway, no time for this anymore, it's going to be 2010 soon here.
>>>>
>>>>> Bye,
>>>>> bearophile
>>> Someone reported the regression already:
>>> 
>>> http://d.puremagic.com/issues/show_bug.cgi?id=3663
>> 
>> It's caused by the patch for bug 400.
> 
> Thanks, that fixed it.
> 
> But now there is another problem/regression:
> 
> tango/net/device/Berkeley.d(1065): Error: enum member
> tango.net.device.Berkeley.IPv4Address.ADDR_ANY conflicts with enum
> member tango.net.device.Berkeley.IPv4Address.ADDR_ANY at
> tango/net/device/ Berkeley.d(1065)
> tango/net/device/Berkeley.d(1066): Error: enum member
> tango.net.device.Berkeley.IPv4Address.ADDR_NONE conflicts with enum
> member tango.net.device.Berkeley.IPv4Address.ADDR_NONE at tango/net/
> device/Berkeley.d(1066)
> tango/net/device/Berkeley.d(1067): Error: enum member
> tango.net.device.Berkeley.IPv4Address.PORT_ANY conflicts with enum
> member tango.net.device.Berkeley.IPv4Address.PORT_ANY at
> tango/net/device/ Berkeley.d(1067)

I've made a ticket: http://d.puremagic.com/issues/show_bug.cgi?id=3664

(tested with original dmd 1.054)

Moritz Warning wrote:
> On Fri, 01 Jan 2010 22:35:12 +0000, Moritz Warning wrote:
> 
>> On Fri, 01 Jan 2010 19:31:49 +0100, Don wrote:
>>
>>> Moritz Warning wrote:
>>>> On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:
>>>>
>>>>> bearophile wrote:
>>>>>> grauzone:
>>>>>>> But I have a problem: the compiler is either extremely slow for me,
>>>>>>> or is stuck in an endless loop. All it does is to slowly allocate
>>>>>>> memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM
>>>>>>> allocation. This wasn't the case with dmd 1.053, where it only took
>>>>>>> 5-10 seconds to compile. Can anyone confirm this?
>>>>>> Show the code!
>>>>> I was going to say "but it's hundreds of modules", but then I tried
>>>>> to compile some other big hog of code: Tango.
>>>>>
>>>>> And I found compiling this file hangs:
>>>>> http://dsource.org/projects/tango/browser/trunk/tango/core/tools/
>>>> Demangler.d?rev=5248
>>>>> The exact command line for this was:
>>>>> dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
>>>>> -oftango-core-tools-Demangler-release.o
>>>>> ../tango/core/tools/Demangler.d
>>>>>
>>>>> Again, could anyone confirm this?
>>>>>
>>>>> Anyway, no time for this anymore, it's going to be 2010 soon here.
>>>>>
>>>>>> Bye,
>>>>>> bearophile
>>>> Someone reported the regression already:
>>>>
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=3663
>>> It's caused by the patch for bug 400.
>> Thanks, that fixed it.
>>
>> But now there is another problem/regression:
>>
>> tango/net/device/Berkeley.d(1065): Error: enum member
>> tango.net.device.Berkeley.IPv4Address.ADDR_ANY conflicts with enum
>> member tango.net.device.Berkeley.IPv4Address.ADDR_ANY at
>> tango/net/device/ Berkeley.d(1065)
>> tango/net/device/Berkeley.d(1066): Error: enum member
>> tango.net.device.Berkeley.IPv4Address.ADDR_NONE conflicts with enum
>> member tango.net.device.Berkeley.IPv4Address.ADDR_NONE at tango/net/
>> device/Berkeley.d(1066)
>> tango/net/device/Berkeley.d(1067): Error: enum member
>> tango.net.device.Berkeley.IPv4Address.PORT_ANY conflicts with enum
>> member tango.net.device.Berkeley.IPv4Address.PORT_ANY at
>> tango/net/device/ Berkeley.d(1067)
> 
> I've made a ticket:
> http://d.puremagic.com/issues/show_bug.cgi?id=3664
> 
> (tested with original dmd 1.054)
That's also caused by the other half of the patch for 400, in class.c.

Am 31.12.2009 19:48, schrieb Walter Bright:
> Happy New Year!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.054.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.038.zip
>
> Many thanks to the numerous people who contributed to this update.

Great to see so many fixes that make the language much more hassle-free to use - especially for newcomers that hit such things for the first time. However, I have at least one blocker problem in this release:

Because of the now disallowed struct initializers for structs with constructors (bug 3476), there is no way to use those structs as static immutable values as the constructors are not CTFE processable.

(-> Error: cannot evaluate ((X __ctmp2;
) , __ctmp2).this() at compile time)

This problem has been there since struct constructors have been introduced. A quick search on bugzilla did not return a matching
bug report, only some other issues related to struct constructors. I'll file a bug report if noone else knows of any existing one (technically this would be an 'improvement', but I think it is a really important issue).

This exact place in my code (something like struct Vector(S){ static invariant Vector zero = Vector(0, 0); }) had to be modified after almost every compiler release and also rendered a lot of versions useless for me because there was somtimes no real workaround.

BTW: I was not really watching the newsgroups lately and just noticed the DIP2/inout implementation. IMO 'inout' is really not a good choice for the keyword, introducing a backwards imcompatibility, changing the meaning of a de-facto standard keyword (IDL etc) and not really hitting the point (placeholder for const/immutable/nothing). Also if I did not know about the concept of DIP2 such code would have been a mystery for me.

Sönke

Sönke Ludwig:
> BTW: I was not really watching the newsgroups lately and just noticed the DIP2/inout implementation. IMO 'inout' is really not a good choice for the keyword, introducing a backwards imcompatibility, changing the meaning of a de-facto standard keyword (IDL etc) and not really hitting the point (placeholder for const/immutable/nothing). Also if I did not know about the concept of DIP2 such code would have been a mystery for me.

It seems that Walter has yet to learn that names are important. Using nearly random words (and syntax) to express ideas and features, as currently done in D2, is bad. It's the silly "invariant" / "immutable" story again.

Python devs ask all people how to name things before, and then Guido V. R. picks the most popular name. They do this because a single person may have some bias: what is intuitive for a person (like Guido, or Walter, or Andrei) may be not intuitive for most other people. Choosing one of the most popular choices can't solve all problems, but it helps finding a name/syntax that will result intuitive for most future programmers.

Bye,
bearophile

bearophile wrote:
> Sönke Ludwig:
>> BTW: I was not really watching the newsgroups lately and just
>> noticed the DIP2/inout implementation. IMO 'inout' is really not a
>> good choice for the keyword, introducing a backwards
>> imcompatibility, changing the meaning of a de-facto standard
>> keyword (IDL etc) and not really hitting the point (placeholder for
>> const/immutable/nothing). Also if I did not know about the concept
>> of DIP2 such code would have been a mystery for me.
> 
> It seems that Walter has yet to learn that names are important. Using
> nearly random words (and syntax) to express ideas and features, as
> currently done in D2, is bad. It's the silly "invariant" /
> "immutable" story again.
> 
> Python devs ask all people how to name things before, and then Guido
> V. R. picks the most popular name. They do this because a single
> person may have some bias: what is intuitive for a person (like
> Guido, or Walter, or Andrei) may be not intuitive for most other
> people. Choosing one of the most popular choices can't solve all
> problems, but it helps finding a name/syntax that will result
> intuitive for most future programmers.
> 
> Bye, bearophile

The discussion on the name is here:

http://www.digitalmars.com/d/archives/digitalmars/D/transporting_qualifier_from_parameter_to_the_return_value_103609.html

And no, it was not random.

Walter Bright:
> And no, it was not random.

Sorry for showing disrespect for your work, it has slipped me. I have used a wrong wording.
Do you see a correlation between the "inout" word and the semantics of this feature? I think this connection is not intuitive.
What are the alternative words that can be used here? Are those a worse choice? What are the most intuitive words for most people? Is this feature worth introducing a keyword?

Bye,
bearophile