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.


T

-- 
Computers shouldn't beep through the keyhole.

On Mon, Apr 30, 2012 at 08:46:02PM +0200, Timon Gehr wrote:
> On 04/30/2012 05:36 PM, H. S. Teoh wrote:
[...]
> >So far, I've not seen a single response in favor of keeping the comma operator.
[...]
> 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.

We already have a reuse waiting in the line up, for a looong time. Native tuple syntax.


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye

On 4/28/2012 11:47 AM, Walter Bright wrote:
> Andrei and I had a fun discussion last night about this question. The idea was
> which features in D are redundant and/or do not add significant value?
>
> A couple already agreed upon ones are typedef and the cfloat, cdouble and creal
> types.
>
> What's your list?

This certainly seems to have become the biggest thread ever!

On 5/1/12 2:24 AM, Walter Bright wrote:
> On 4/28/2012 11:47 AM, Walter Bright wrote:
>> Andrei and I had a fun discussion last night about this question. The
>> idea was
>> which features in D are redundant and/or do not add significant value?
>>
>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>> and creal
>> types.
>>
>> What's your list?
>
> This certainly seems to have become the biggest thread ever!

On Monday, 30 April 2012 at 19:24:50 UTC, Walter Bright wrote:
> On 4/28/2012 11:47 AM, Walter Bright wrote:
>> Andrei and I had a fun discussion last night about this question. The idea was
>> which features in D are redundant and/or do not add significant value?
>>
>> A couple already agreed upon ones are typedef and the cfloat, cdouble and creal
>> types.
>>
>> What's your list?
>
> This certainly seems to have become the biggest thread ever!

Yes, this is a very interesting discussion, even for a n00b like me ! (and even if i didn't understand everything)

On 2012-04-30 17:14, Alex Rønne Petersen wrote:
> On 30-04-2012 09:08, Jacob Carlborg wrote:
>> On 2012-04-29 22:26, Alex Rønne Petersen wrote:
>>
>>> IMHO r"" is better than `` for the simple reason that typing `` is
>>> extremely annoying on non-US keyboards.
>>
>> `` is better because you don't have to escape ".
>>
>
> That only applies when you actually have " in the string. I think both
> have their uses.
>

When is r"" a better use than ``? We already have the regular "".

-- 
/Jacob Carlborg

On 2012-04-30 17:27, Alex Rønne Petersen wrote:
> On 30-04-2012 09:58, Jacob Carlborg wrote:

>> I would rather have @property on instance variables be a syntax sugar
>> for implementing property functions. Basically virtual instance
>> variables.
>>
>
> Then there better be a way to mark them final too. ;)
>

Then what's the point of having a method? Just use a public instance variable.

-- 
/Jacob Carlborg

On 4/30/2012 10:04 AM, Jonathan M Davis wrote:
> I never claimed that I _was_ Walter. I was pointing out that there's very
> little consensus in this thread (almost all of the comments are in conflict
> with other comments) so that even if it was our intention to go and remove
> things from the language based on this thread, there is very little, if
> anything, that has a clear consensus on being removed. The closest would
> probably be the comma operator, and there wasn't even a complete consensus on
> _that_.

There is less agreement than I thought there would be.

This thread also generated far more interest than I anticipated.

> And while I obviously can't say for certain what Walter intended, it was my
> impression that the point of this thread was more out of curiosity and for
> "lessons learned" from designing D than to actually make any changes to the
> language right now (especially when you consider how much Walter hates
> breaking backwards compatibility). But obviously, he'd have to clarify for us
> to know for sure.

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.

So we're talking several years out.

The evolution of C++ is interesting. So far, the C++ committee has shown incredible resistance to removing, or even deprecating, some features that pretty much everyone knows were a mistake, all in the interests of maintaining backwards compatibility. Some of C++'s success can be attributed to that, but also some of its endemic failures.

Where's the line to draw between breaking existing code and modernizing / removing cruft / removing support for features that promote bad code? Of
course, there can't be any fixed rule for that. Hearing peoples' opinions on it on a case by case basis helps a lot.

We've had some success in deprecating mistaken features - the bit data type, and typedefs.

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.

On 4/29/2012 5:26 AM, David Nadlinger wrote:
> - Anonymous nested classes: They might be useful in Java, particularly in older
> incarnations, but not so much in D – never used them.

I don't like them, either, but they were put in at the recommendation of people who were porting large piles of Java code to D. It made semi-mechanical translation much more feasible.

Using them for any other purpose is likely a bad idea, as the only reason they exist in Java is as a kludge to work around limitations in Java.

On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
> I'm surprised nobody has mentioned opApply.

opApply is great. I find myself finding new, kinda
crazy things to do with it every so often, like
concurrency sugar.