On 05/01/2012 01:30 AM, Andrej Mitrovic wrote:
> On 5/1/12, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>> On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
>>> On 5/1/12, Timon Gehr<timon.gehr@gmx.ch>   wrote:
>>>> D2 ->   D3 will be full of breaking changes anyway.
>>>
>>> Uhmm I hope not,
>>
>> Then what is the point of D3?
>
> An incremental improvement with as little code breakage as possible?

IMHO that is similar to aiming for some code breakage with as little
improvement as possible. Retainment of backwards-compatibility is what makes languages convoluted. Furthermore, the translation from D2->D3
should be possible to be performed automatically.

> You can't  even properly mix D1 and D2 code in the same library right now


> without resorting to using mixin() tricks.

This means you actually can!

On Tue, May 01, 2012 at 02:14:42AM +0200, bearophile wrote:
> Timon Gehr:
> 
> >* I agree on supporting deducing length for static arrays. (there is a
> >  int[$] arr = [1,2,3]; proposal.)
> 
> Someone in Bugzilla ha just proposed an alternative idea, that despite not looking very nice, is not overall bad (here with a small change):
> 
> auto arr = [1, 2, 3]f;
> 
> That trailing f denotes a fixed-side array/string literal. So it's usable for other situations too.
[...]

I don't like it. An f prefix already means float in another context; overloading it to also mean static array is a bad idea. D already has too much overloaded syntax (like static meaning all sorts of diverse things depending on context). I much prefer the int[$] proposal, because $ already means "length of array" in D, and so would fit right in.


T

-- 
We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare.  Now, thanks to the Internet, we know this is not true. -- Robert Wilensk

On Tuesday, May 01, 2012 01:30:11 Andrej Mitrovic wrote:
> On 5/1/12, Timon Gehr <timon.gehr@gmx.ch> wrote:
> > On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
> >> On 5/1/12, Timon Gehr<timon.gehr@gmx.ch> wrote:
> >>> D2 -> D3 will be full of breaking changes anyway.
> >> 
> >> Uhmm I hope not,
> > 
> > Then what is the point of D3?
> 
> An incremental improvement with as little code breakage as possible? You can't even properly mix D1 and D2 code in the same library right now without resorting to using mixin() tricks.

But you could do that without creating a D3. Once the implemnetation has stabilized, it should be possible to add new features to D2 as long as they're backwards compatible (e.g. adding user-defined attributes). The only reason to create D3 would be if we wanted to make changes which _weren't_ backwards compatible.

- Jonathan M Davis

On Tuesday, 1 May 2012 at 00:02:37 UTC, Timon Gehr wrote:
> * how p[0..len] can be seen as an issue instead of as great completely escapes my mind.

 I can only offer my own experiences. When I first saw D1 and saw ranges used like that, it looked like pure greek and confused the hell out of me. I mean, what is this ..? How does it work? Only after a lightbulb appearing over my head did I realize .. was just another operator, which didn't exist in C or C++.

 Having the example completely broken down into equiv D code that doesn't use the .. makes it's use and glue to the compiler a bit more obvious and fills in the gaps. I mean, how would you take a foreign symbols of << 1->End >> to be?  If you squint, it's just a slightly different syntax for the same thing; depending on how you interpret the languages(s).

On Sunday, 29 April 2012 at 20:50:02 UTC, Alex Rønne Petersen wrote:

>> - in operator
>
> Disagree. However, I do think it needs to made more useful (for instance, I simply don't understand why I can't use in to test for existence in an array).

Complexity of the operation. in on an array is not nearly the same as with an associative array.

On 01-05-2012 03:41, Jesse Phillips wrote:
> On Sunday, 29 April 2012 at 20:50:02 UTC, Alex Rønne Petersen wrote:
>
>>> - in operator
>>
>> Disagree. However, I do think it needs to made more useful (for
>> instance, I simply don't understand why I can't use in to test for
>> existence in an array).
>
> Complexity of the operation. in on an array is not nearly the same as
> with an associative array.

I know, but it's very intuitive still; see Python.

-- 
- Alex

On 01-05-2012 02:14, bearophile wrote:
> Timon Gehr:
>
>> * I agree on supporting deducing length for static arrays. (there is a
>> int[$] arr = [1,2,3]; proposal.)
>
> Someone in Bugzilla ha just proposed an alternative idea, that despite
> not looking very nice, is not overall bad (here with a small change):
>
> auto arr = [1, 2, 3]f;
>
> That trailing f denotes a fixed-side array/string literal. So it's
> usable for other situations too.
>
>
>> * the foo(a,&b) example is biased because it uses a meaningless
>> function name. From the function name alone it is often *almost*
>> clear that a certain argument will be modified. & & & spam is not
>> 'clean' either.
>
> In C# you need to use "ref" and "out" at the calling point (in most
> cases). D language has chosen a different design, but here C# design has
> some advantages too, it makes the code semantics a bit more clear.

Tell me about it... I've had a few WTF and WAT moments due to D's design here.

>
> Bye,
> bearophile

-- 
- Alex

On 4/28/2012 1:32 PM, Timon Gehr wrote:
> On 04/28/2012 10:02 PM, Walter Bright wrote:
>> On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
>>> Also there's mixin templates. What exactly is the difference between
>>> mixin templates and regular templates?
>>
>> A mixin template is instantiated in context of the instantiation point,
>> while a regular template is instantiated in the context of the template
>> definition point.
>>
>> This becomes relevant when looking up symbols that are not defined
>> within the template.
>
> The implementation seems to disagree:
>
> int x;
> template X(){ // not a mixin template
> void y(){x=2;}
> }
>
> class C{
> int x;
> mixin X; // picks up local 'x'

Makes it a mixin template.

> }
>
> void main(){
> auto c = new C;
> c.y();
> import std.stdio;
> writeln(x," ",c.x); // "0 2"
> }
>
> Or am I misunderstanding your statement?

The behavior is as I described.

On Tuesday, 1 May 2012 at 02:26:53 UTC, Alex Rønne Petersen wrote:
> On 01-05-2012 03:41, Jesse Phillips wrote:
>>
>> Complexity of the operation. in on an array is not nearly the same as
>> with an associative array.
>
> I know, but it's very intuitive still; see Python.

And that's why it's somewhat dangerous. Because it's so easy to use, someone that doesn't pay enough attention may overlook the fact that he is not using the right data structure. If he often has to do that more than once, he is using the wrong tool for the job. I agree it would be syntaxically nice, but I worry giving this syntactic sugar for what's a for loop with lots of comparisons isn't such a good idea. And the comparisons themselves are subject to caution. If for instance it's an array of floats, or some custom objects, it's very unlikely that you are going to compare bit by bit. So basically, this would be useful only for integers and chars.

On Monday, 30 April 2012 at 22:04:16 UTC, deadalnix wrote:
> 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.

Also consider that at least on many European keyboard layouts,
',' and ';' share the same key…

David