Le 29/04/2012 03:06, bearophile a écrit :
> Jonathan M Davis:
>
>> * foreach_reverse is essentially redudant at this point (not to mention
>> confusing if combined with delegates), since we have retro.
>
> retro() can't replace foreach_reverse until the front-end
> demonstrability produces asm code equally efficient.
> Loops _must_ be fully efficient, they are a basic language construct,
> this is very important. Even foreach() is sometimes not equally
> efficient as a for() in some cases...
>

This is an implementation issue and shouldn't be an argument for language design.

On Sunday, 29 April 2012 at 19:19:51 UTC, David Nadlinger wrote:
> On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote:
> What I forgot to mention:
>  - VersionCondition: Just provide a mechanism to map command line flags to constants, probably in a magic »version« namespace, and use static if (e.g. »version (Foo)« -> »static if (version.Foo)«, »version (unittest)« -> »static if (unittest)«).
>

It sounds indeed nice, but I prefer convention over configuration. Experience has shown that it makes things simpler.

Le 29/04/2012 22:54, Alex Rønne Petersen a écrit :
> D unit tests were never really useful for anything beyond single-library
> projects IMHO. They don't scale for large, real-world application
> projects with lots of libraries and executables.
>

+1 A good std.unittest + attributes is probably a better approach.

On Saturday, 28 April 2012 at 19:58:03 UTC, foobar wrote:
> * di files - a library should encapsulate all the info required
> to use it. Java Jars, .Net assemblies and even old school; Pascal
> units all solved this long ago.

I strongly support this.

On 04/29/2012 10:03 PM, Alex Rønne Petersen wrote:
> On 28-04-2012 23:41, Timon Gehr wrote:
>>
>> As I understand it, the 'agreed upon' design is that
>>
>> @property int foo() { return x; }
>> @property void foo(int v) { x = v; }
>>
>> Would be completely equivalent to C#:
>>
>> int foo { set{ x = value; }; get{ return x; } }
>
> Nope.
>
> First of all, you'd have to declare the setter like this in D:
>
> @property int foo(int v) { return x = v; }
>
> so that you can write:
>
> int v = obj.foo = 1; // valid C#
>
> Next up is the issue of op-assign operations. In D, you can't do:
>
> obj.foo += 1;
> obj.foo++;
>
> while in C#, you can (it results in a get -> add 1 -> set and get -> inc
> -> set, etc).
>

I didn't say this was how it worked in the current compiler implementation. But I may be wrong on what is the design because I didn't take part in that discussion.

Notably, read-update operations now work on the built-in length property of arrays. I don't think there is any justification for not implementing this for properties.

On Sunday, 29 April 2012 at 21:18:40 UTC, deadalnix wrote:
> Le 29/04/2012 03:06, bearophile a écrit :
>> Jonathan M Davis:
>>
>>> * foreach_reverse is essentially redudant at this point (not to mention
>>> confusing if combined with delegates), since we have retro.
>>
>> retro() can't replace foreach_reverse until the front-end
>> demonstrability produces asm code equally efficient.
>> Loops _must_ be fully efficient, they are a basic language construct,
>> this is very important. Even foreach() is sometimes not equally
>> efficient as a for() in some cases...
>>
>
> This is an implementation issue and shouldn't be an argument for language design.

The 'sufficiently smart compiler' argument is old and invalid. Please do not use it.

On Sunday, 29 April 2012 at 21:23:41 UTC, SomeDude wrote:
> On Sunday, 29 April 2012 at 19:19:51 UTC, David Nadlinger wrote:
>> What I forgot to mention:
>> - VersionCondition: Just provide a mechanism to map command line flags to constants, probably in a magic »version« namespace, and use static if (e.g. »version (Foo)« -> »static if (version.Foo)«, »version (unittest)« -> »static if (unittest)«).
>
> It sounds indeed nice, but I prefer convention over configuration. Experience has shown that it makes things simpler.

What exactly does this have to do with »convention over configuration«? The big problem with version conditionals is that they introduce a heavily restricted subset of static if, i.e. a whole new language construct, for questionable benefits.

David

On 29 April 2012 23:00, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> On 28-04-2012 23:18, SomeDude wrote:
>
>> Yeah, but core language AA are so useful it would be a MAJOR mistake to remove them. In Python too, you could put the AA in the libraries. Yet everybody uses the AA that are in the language.
>>
>> Where I DO agree with you is, Phobos should be a two level library, i.e a minimalistic library, with about the same feature set as the standard C library + multithreading, and a superset with the full range of features (ranges, algorithms, etc). I've already advocated it somewhere else.
>>
>
> Let's get a standard package manager that we either advocate on dlang.orgor include in the releases before we start talking about reducing the
> amount of modules in Phobos.


Oh hell yes! I have exciting dreams of something like this every other night ;)

On 29-04-2012 23:54, Peter Alexander wrote:
> On Sunday, 29 April 2012 at 21:18:40 UTC, deadalnix wrote:
>> Le 29/04/2012 03:06, bearophile a écrit :
>>> Jonathan M Davis:
>>>
>>>> * foreach_reverse is essentially redudant at this point (not to mention
>>>> confusing if combined with delegates), since we have retro.
>>>
>>> retro() can't replace foreach_reverse until the front-end
>>> demonstrability produces asm code equally efficient.
>>> Loops _must_ be fully efficient, they are a basic language construct,
>>> this is very important. Even foreach() is sometimes not equally
>>> efficient as a for() in some cases...
>>>
>>
>> This is an implementation issue and shouldn't be an argument for
>> language design.
>
> The 'sufficiently smart compiler' argument is old and invalid. Please do
> not use it.
>

Indeed; at some point, you have to admit that implementation will have some impact on design. We don't live an ideal world, unfortunately. ;)

-- 
- Alex

On 04/29/2012 10:59 PM, Alex Rønne Petersen wrote:
> On 29-04-2012 14:26, David Nadlinger wrote:
>> - Unsigned right shift, but I can see how it can be useful (simply
>> underused?).
>
> It's clear that arithmetic right shift is what the programmer usually
> wants, and yet, we use >> to denote what they don't want. It's
> completely counter-intuitive.
>
> So, +1.
>

'>>' is arithmetic right shift.

>>
>> - shared: TLS by default is great, but only __gshared is really usable
>> right now. IMHO, shared had better been reserved for a comprehensive
>> take on the subject, rather than the half-baked implementation we have
>> right now.
>>
>> David
>
> It's clear that shared is biased towards heavily templatized code.
> It's not useful in non-templatized code because such code can't accept both
> shared and non-shared values.

Just cast it away if you do eg. locking. There is nothing wrong with it.
Code that operates on both (actually) shared and unshared data should be uncommon anyway.

>
> shared looks neat in theory, but is a fallacy in practice.
>

unshared is what is important. There is no unshared if there is no shared.