Le 30/04/2012 22:44, bearophile a écrit :
> Timon Gehr:
>
>> I think I use it about every 60 lines of code. Also, I don't think it
>> should be removed for the sake of removing it. If it is removed, the
>> syntax should be reused.
>
> Commas do cause some bugs, so maybe they are worth restricting (further)
> even if their syntax doesn't get reused.
>
> Bye,
> bearophile

+1

Looking for a , instead of a ; is really painful. It doesn't occur often, but when it does, you remember it for quite a long time.

Le 30/04/2012 22:52, SomeDude a écrit :
> In the end, very few "features" seem to be universally disdained (the
> comma operator seems to come regularly, though, but even that one has
> supporters). Which means to me that in terms of overall design, the
> language is not in a bad shape at all.

I wouldn't say supporter, but some people think it doesn't worth the cost of breaking code.

BTW, you'll find lazy too.

On Monday, 30 April 2012 at 16:54:48 UTC, Iain Buclaw wrote:
>
>
> Having said that, I did produce a report from GDC once with a list of
> times it takes to compile D2 code (in this instance, libphobos and
> druntime).
>
> http://iainbuclaw.files.wordpress.com/2010/09/d2-time-report2.pdf
>
> TOTAL is the total time taken (ie: 0.08 seconds in the first file),
> and the other elements are a breakdown of what passes took the longest
> amount of processing time during the entire compilation.
>
>
> If you could get DMD to pull off a similar report, you'd have
> something nice to compare to. ;-)
>
>
> Regards

Thx, that's interesting.

On 30.04.2012 23:14, H. S. Teoh wrote:
> On Mon, Apr 30, 2012 at 09:06:06PM +0200, Andrej Mitrovic wrote:
>> On 4/30/12, H. S. Teoh<hsteoh@quickfur.ath.cx>  wrote:
>>> Then
>>> you can write:
>>>
>>> 	uint[] a = [
>>> 		2: 100,
>>> 		10: 200
>>> 	]
>>>
>>> and it will be equivalent to:
>>>
>>> 	uint[] a = [0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 200];
>>
>> But you can already use this syntax right now?
>
> Yes I know you can, it was more of using this syntax for user-defined
> types without allocating a temporary array.
>

Yes I tried to point out that this also makes this code straight forward. AND allows other AA-like enitites to benefit from it.

Most importantly it doesn't break a thing. Just generalizes.
-- 
Dmitry Olshansky

On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
[...]
>
> I'm surprised nobody has mentioned opApply. That was a good idea at the time, but Ranges are a superior solution. I'd like to see new code not use opApply. It's a dead end, though it'll still be supported for a long time.

Both internal and external iteration have their pros and cons. It doesn't make sense to claim one is superior to the other.

Ranges are more appropriate for serial code whereas internal iteration is better suited for concurrent code.

On 04/30/2012 11:28 PM, bearophile wrote:
> Walter:
>
>> The first thing to emphasize is that NONE of this will happen for D2.
>> The emphasis on D2 is fixing implementation and toolchain issues.
>> Breaking existing code is off the table unless we are pretty much
>> forced to in order to fix some other more important issue.
>
> But you need to keep into account that D2 is still a not widely used
> language. So deprecating some things now will cause far less troubles
> than doing it in D3 some years from now.

D2 -> D3 will be full of breaking changes anyway. Otherwise there is no reason to add another major language version.

On 05/01/2012 12:12 AM, deadalnix wrote:
> Le 30/04/2012 22:52, SomeDude a écrit :
>> In the end, very few "features" seem to be universally disdained (the
>> comma operator seems to come regularly, though, but even that one has
>> supporters). Which means to me that in terms of overall design, the
>> language is not in a bad shape at all.
>
> I wouldn't say supporter, but some people think it doesn't worth the
> cost of breaking code.
>
> BTW, you'll find lazy too.

call by name is useful.

On 04/29/2012 12:12 PM, Nick Sabalausky wrote:
> "Timon Gehr"<timon.gehr@gmx.ch>  wrote in message
> news:jnj92m$306m$1@digitalmars.com...
>> On 04/29/2012 08:35 AM, Nick Sabalausky wrote:
>>
>>> it's just a series of manifest
>>> constants. The fact that they're grouped doesn't even have any semantic
>>> consequence, as far as I'm aware.
>>
>> The only differences are that they don't occupy their own namespace and
>> they don't define their own type. But non-anonymous enums are _just a
>> bunch of manifest constants_ as well!
>
> No, they're not. Non-anon enums *contain* a bunch of manifest constants. But
> what non-anon enums *are* is a type. Anon enums are not a type at all. I
> think that's a significant difference.

I see that way as well. I have a section titled "enum values that are not of an enum type" at http://ddili.org/ders/d.en/enum.html:

[quote]
sometimes it may not be natural to come up with enum type names just to use named constants. Let's assume that a named constant is needed to represent the number of seconds per day. It should not be necessary to also define an enum type for this constant value. All that is needed is a constant value that can be referred to by its name. In such cases, the type of the enum and the value parentheses are not specified:

    enum secondsPerDay = 60 * 60 * 24;
[/quote]

> Of course, my biggest issue by far is with the name "enum".

Agreed. It became a bad name as soon as any value other than a number could be an enum value (or "member").

> Non-anon enums
> can reasonably be thought of as enumerations (except for bitfields, but I
> think those should be handled differently from enums anyway). But anon-enums
> are just plain not enumerations, period. If we weren't calling them all
> "enum", then I would have much, much less problem with the syntax we have.
> And yea, I get the whole "What's in a name?", but "enum" is just a
> colossally *terrible* name for this. It's worse than when "immutable" was
> called "invariant".

Ali

On 5/1/12, Timon Gehr <timon.gehr@gmx.ch> wrote:
> D2 -> D3 will be full of breaking changes anyway.

Uhmm I hope not, otherwise D3 will be dead in the water.

On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
>
> I'm surprised nobody has mentioned opApply. That was a good idea at the time, but Ranges are a superior solution. I'd like to see new code not use opApply. It's a dead end, though it'll still be supported for a long time.

I practically never use ranges, and instead use opApply for all my code.

1) Ranges force me to use a specific naming convention. My naming convention that I use for my projects is upper camel case. Ranges do not allow this. Technically opApply is still lower camel case, but my code doesn't directly call it.

2) Ranges don't have a way of determining when the iteration ends. Sometimes you want to do something once iteration stops. For example, by far the most common action when executing a database call for me, is to iterate over it and close it. I can then have a helper method that executes the command and closes it when the foreach is done (whether by break or by the function ending). This saves quite a bit of boiler plate code.

3) Ranges can be difficult to implement. You now have to keep track of state instead of simply leaving everything inside a single method call. This can also cause significant problems with multi-threaded code.

4) Ranges take a lot more code, which when all you want is basic iteration, is pointless to have.

I'd much rather just see things with opApply being able to have a forward-range magically created for it, much like the reverse. Not sure if this is possible or practical though.