July 25, 2006
Chris Nicholson-Sauls wrote:
> Don Clugston wrote:
> 
>> Nooooooooo!!!!
>> Am I the only person who has hundreds of local variables called 'var'?
>> (mostly variants in Win32 code).
>>
>> A quick google search for 'var cpp' showed a million hits, a fair chunk of them are local variables in C++ code. It's a very popular variable name.
> 
> 
> Actually I do feel your pain, but I still vote for it.  Waaay back in the day I used to do a lot of LambdaMOO server hacking, and therein I discovered my first Var struct.  (That'd be about 1996 I think it was.)  Now, ten years later, I am working on BovisMOO... and I'm still using a Var struct (albeit a much cleaner one), and plenty of temporary Var's named, yes, 'var.'
> 
> But I can always just rename them to 'tmp', or something else.  (Actually a lot of them would probably get renamed 'result' since that's what they generally are.)
> 
> -- Chris Nicholson-Sauls

I suspect the focus should be directed elsewhere, Chris?

There's nothing wrong with using "auto" for implicit-type -- it's the confusion with raii that's the issue, yes?

I suspect the ratio of raii usage to implicit-type usage would be overwhelmingly in favour of the latter. Thus, it would seem to make sense to leave implicit-type "auto" just as it is, and change raii to use something else instead; such as "scope" ?

void main()
{
  auto i = 10;
  auto foo = new Foo;
  auto scope bar = new Bar;
  auto scope wumpus = new Wumpus;
}

class Foo {}

class Bar {}

scope class Wumpus {}




July 25, 2006
Lionello Lunesu wrote:
> 
> 
> I think "static opCall" is a hack to begin with. It's basically a workaround for structs not having constructors. For classes, there's no point in having a static opCall if Walter implements the "A()" construct.
> 

I disagree.  I like being able to use types as functions.
Here's one example where I do something similar to what you'd use nested functions for, but better - my forward referencing woes go away.

class F
{
    int result;
    int tempVar1;

    static int opCall( int x )
    {
        F f = new F(x);
        int result = f.result;
        delete f;
        return result;
    }

    this( int x )
    {
        internalFunc1();
        // do stuff
    }

    private void internalFunc1()
    {
        if ( maybe )
            internalFunc2();
        else return;
    }

    private void internalFunc2()
    {
        if ( maybe )
            internalFunc1();
        else return;
    }
}

void main()
{
    int x = 42;
    x = F(x);
}

Under the hood, it may also behave differently than nested functions, which could be advantageous.  I'm not sure that it is advantageous, but options are always nice.

That and you can make nice syntax sugars for alternative memory management methods like freelists, without messing with overriding 'new()'.

> 
> 
> I also prefer "var" to "auto" for the type inference. I don't think anybody expects "var" to be dynamically typed. Well, maybe a few. And then there's the "auto" from C++; it might confuse people if its meaning were changed.
> 
> L.
July 26, 2006
kris wrote:
> Chris Nicholson-Sauls wrote:
> 
>> Don Clugston wrote:
>>
>>> Nooooooooo!!!!
>>> Am I the only person who has hundreds of local variables called 'var'?
>>> (mostly variants in Win32 code).
>>>
>>> A quick google search for 'var cpp' showed a million hits, a fair chunk of them are local variables in C++ code. It's a very popular variable name.
>>
>>
>>
>> Actually I do feel your pain, but I still vote for it.  Waaay back in the day I used to do a lot of LambdaMOO server hacking, and therein I discovered my first Var struct.  (That'd be about 1996 I think it was.)  Now, ten years later, I am working on BovisMOO... and I'm still using a Var struct (albeit a much cleaner one), and plenty of temporary Var's named, yes, 'var.'
>>
>> But I can always just rename them to 'tmp', or something else.  (Actually a lot of them would probably get renamed 'result' since that's what they generally are.)
>>
>> -- Chris Nicholson-Sauls
> 
> 
> I suspect the focus should be directed elsewhere, Chris?
> 
> There's nothing wrong with using "auto" for implicit-type -- it's the confusion with raii that's the issue, yes?
> 
> I suspect the ratio of raii usage to implicit-type usage would be overwhelmingly in favour of the latter. Thus, it would seem to make sense to leave implicit-type "auto" just as it is, and change raii to use something else instead; such as "scope" ?
> 
> void main()
> {
>   auto i = 10;
>   auto foo = new Foo;
>   auto scope bar = new Bar;
>   auto scope wumpus = new Wumpus;
> }
> 
> class Foo {}
> 
> class Bar {}
> 
> scope class Wumpus {}
> 

Actually that does make some sense, and I do like the meaningful re-use of an existing keyword over inventing a new one.  (Honestly I hadn't even considered 'scope' for this, even though it does make obvious sense!)  Although, I find myself almost wanting to make it 'scoped' for this (note the -d on the end), as that's what it is really meaning, but A) then it becomes a new keyword anyway, and B) it begs for typos.

I think you may've converted me.

-- Chris Nicholson-Sauls
July 26, 2006
Chad J wrote:
>>> class A {}
>>>
>>> A a = new A(); //normal
>>> A a = A(); //destroyed at end of scope
>>>
>>> and with auto..
>>>
>>> auto a = new A(); //normal
>>> auto a = A(); //destroyed at end of scope
>>>
>>> Simple, elegant, obvious (IMO) 
>>
>>
> 
> Myself I would prefer not to have that.  It creates an ambiguity between  a static opCall on A and the storage attribute.
> So:
> 
> class A
> {
>   static A opCall() { ...do something... }
> }
> 
> A a = A(); // destroyed at end of scope, or call A.opCall()?
> 
> I prefer the storage attribute have it's own keyword.  Perhaps give storage 'auto' and type inference 'var'.  For me, that makes it more obvious, since to my eyes it would be a keyword that I've never seen before and now need to look up in the spec - otherwise it's just a static opCall :(.

The idea is that 'auto' means type inference, not RAII. To get RAII behavior, use A(), which invokes the constructor for A. (If A.opCall is called, it isn't a constructor, and so an RAII object is not created.)

The old syntax:

	auto A a = new A();

will still be supported as a deprecated feature.
July 28, 2006
Oskar Linde wrote:
> Dave skrev:
>> Don Clugston wrote:
>>> Georg Wrede wrote:
>>>> John Demme wrote:
>>>>> Walter Bright wrote:
>>>>>
>>>>>
>>>>>> I think the title says it all.
>>>>>
>>>>>
>>>>> Has anyone recommended that 0.163 should be labelled RC1?  I think this
>>>>> would be fair- hopefully it would focus attention from language changes to
>>>>> finding major bugs/flaws and the "Shop's closed- let's clean up and ship
>>>>> it" mentality.  It would tell people who are maintaining libraries to
>>>>> bother to update them to 0.163 so they will work with 1.0.
>>>>
>>>> This sounds quite reasonable.
>>>
>>> I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>
>>
>> I'm actually hoping that one of the reasons for releasing 1.0 now is because Walter wants to get to work on 2.0 <g> (Not that 1.0 isn't good enough, just that it's fun to "play" :))
>>
>> I'm curious - are there really any "show stopping" type bugs out there for v1.0? By show stopping I mean bugs that completely prevent a given design pattern allowed by the current language spec.
> 
> I'd say the implicit function template instantiation limitations are somewhat show stopping:
> 
> 1. IFTI doesn't work for member functions.
> 2. Partial specialization doesn't work with IFTI.
> 3. Partial template instantiation isn't allowed with IFTI.
> 4. More IFTI limitations...
> 
> Walter has acknowledged that number 2 is a bug. I don't know of any workaround for number 1. Those are all hampering library development, which IMHO would qualify as show stoppers for a 1.0 status.
> 
> Of course, the most important thing is to make clear which limitations are meant to remain and which are to be classified as bugs.
> 
> /Oskar

What is partial specialization ? And Partial template instantiation? (does that come from C++?)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
July 28, 2006
Bruno Medeiros wrote:
> Oskar Linde wrote:
>> Dave skrev:
>>> Don Clugston wrote:
>>>> Georg Wrede wrote:
>>>>> John Demme wrote:
>>>>>> Walter Bright wrote:
>>>>>>
>>>>>>
>>>>>>> I think the title says it all.
>>>>>>
>>>>>>
>>>>>> Has anyone recommended that 0.163 should be labelled RC1?  I think this
>>>>>> would be fair- hopefully it would focus attention from language changes to
>>>>>> finding major bugs/flaws and the "Shop's closed- let's clean up and ship
>>>>>> it" mentality.  It would tell people who are maintaining libraries to
>>>>>> bother to update them to 0.163 so they will work with 1.0.
>>>>>
>>>>> This sounds quite reasonable.
>>>>
>>>> I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>
>>>
>>> I'm actually hoping that one of the reasons for releasing 1.0 now is because Walter wants to get to work on 2.0 <g> (Not that 1.0 isn't good enough, just that it's fun to "play" :))
>>>
>>> I'm curious - are there really any "show stopping" type bugs out there for v1.0? By show stopping I mean bugs that completely prevent a given design pattern allowed by the current language spec.
>>
>> I'd say the implicit function template instantiation limitations are somewhat show stopping:
>>
>> 1. IFTI doesn't work for member functions.
>> 2. Partial specialization doesn't work with IFTI.
>> 3. Partial template instantiation isn't allowed with IFTI.
>> 4. More IFTI limitations...
>>
>> Walter has acknowledged that number 2 is a bug. I don't know of any workaround for number 1. Those are all hampering library development, which IMHO would qualify as show stoppers for a 1.0 status.
>>
>> Of course, the most important thing is to make clear which limitations are meant to remain and which are to be classified as bugs.
>>
>> /Oskar
> 
> What is partial specialization ? And Partial template instantiation? (does that come from C++?)

The term "partial specialization" isn't mentioned in the D spec, but its meaning is documented under "Specialization" in http://www.digitalmars.com/d/template.html
It basically means that you can specialize a template for e.g. all pointers:
template tmp(T:T*) {...}

By partial template instantiation (I have no idea if this is the correct term), I mean specializing a template partially explicitly and partially implicitly.  E.g:

A myCast(A,B)(B x) { return cast(A)x; }
...
myCast!(float)(5);

No template declaration fully matches myCast!(float). It gets partially instantiated and the remaining template parameter B is automatically deduced.

/Oskar
July 28, 2006
Oskar Linde wrote:
> Bruno Medeiros wrote:
>> Oskar Linde wrote:
>>> Dave skrev:
>>>> Don Clugston wrote:
>>>>> Georg Wrede wrote:
>>>>>> John Demme wrote:
>>>>>>> Walter Bright wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I think the title says it all.
>>>>>>>
>>>>>>>
>>>>>>> Has anyone recommended that 0.163 should be labelled RC1?  I think this
>>>>>>> would be fair- hopefully it would focus attention from language changes to
>>>>>>> finding major bugs/flaws and the "Shop's closed- let's clean up and ship
>>>>>>> it" mentality.  It would tell people who are maintaining libraries to
>>>>>>> bother to update them to 0.163 so they will work with 1.0.
>>>>>>
>>>>>> This sounds quite reasonable.
>>>>>
>>>>> I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>
>>>>
>>>> I'm actually hoping that one of the reasons for releasing 1.0 now is because Walter wants to get to work on 2.0 <g> (Not that 1.0 isn't good enough, just that it's fun to "play" :))
>>>>
>>>> I'm curious - are there really any "show stopping" type bugs out there for v1.0? By show stopping I mean bugs that completely prevent a given design pattern allowed by the current language spec.
>>>
>>> I'd say the implicit function template instantiation limitations are somewhat show stopping:
>>>
>>> 1. IFTI doesn't work for member functions.
>>> 2. Partial specialization doesn't work with IFTI.
>>> 3. Partial template instantiation isn't allowed with IFTI.
>>> 4. More IFTI limitations...
>>>
>>> Walter has acknowledged that number 2 is a bug. I don't know of any workaround for number 1. Those are all hampering library development, which IMHO would qualify as show stoppers for a 1.0 status.
>>>
>>> Of course, the most important thing is to make clear which limitations are meant to remain and which are to be classified as bugs.
>>>
>>> /Oskar
>>
>> What is partial specialization ? And Partial template instantiation? (does that come from C++?)
> 
> The term "partial specialization" isn't mentioned in the D spec, but its meaning is documented under "Specialization" in http://www.digitalmars.com/d/template.html
> It basically means that you can specialize a template for e.g. all pointers:
> template tmp(T:T*) {...}
> 
> By partial template instantiation (I have no idea if this is the correct term), I mean specializing a template partially explicitly and partially implicitly.  E.g:
> 
> A myCast(A,B)(B x) { return cast(A)x; }
> ...
> myCast!(float)(5);
> 
> No template declaration fully matches myCast!(float). It gets partially instantiated and the remaining template parameter B is automatically deduced.

An interesting question is if there really is a huge need for this in D. D's templates are already more powerful than C++, and the above example can be written:

template myCast(A) {
	A myCast(B)(B x) {
		return cast(A)x;	
	}
}

(C++ will get this too, one day)

The difference to C++ is (in D syntax), given:

A func(A,B)(B x) { return 1; }
A func(A)(double x) { return 0; }

Then:

In C++, func!(int)(5) would return 1, whereas in D, without partial template instantiation, it would return 0.

C++ may make this more complicated than necessary. IMHO, C++ has too many different ways of achieving polymorphism and they all work together making the overload resolution overly complicated.

/Oskar
July 29, 2006
Oskar Linde wrote:
> Bruno Medeiros wrote:
>> Oskar Linde wrote:
>>>
>>> I'd say the implicit function template instantiation limitations are somewhat show stopping:
>>>
>>> 1. IFTI doesn't work for member functions.
>>> 2. Partial specialization doesn't work with IFTI.
>>> 3. Partial template instantiation isn't allowed with IFTI.
>>> 4. More IFTI limitations...
>>>
>>> Walter has acknowledged that number 2 is a bug. I don't know of any workaround for number 1. Those are all hampering library development, which IMHO would qualify as show stoppers for a 1.0 status.
>>>
>>> Of course, the most important thing is to make clear which limitations are meant to remain and which are to be classified as bugs.
>>>
>>> /Oskar
>>
>> What is partial specialization ? And Partial template instantiation? (does that come from C++?)

Oops, I was going to google a bit before asking, but the message got sent first. I still searched, so I would know how it is done in C++ (I know basic C++, but not C++ templates).

> 
> The term "partial specialization" isn't mentioned in the D spec, but its meaning is documented under "Specialization" in http://www.digitalmars.com/d/template.html
> It basically means that you can specialize a template for e.g. all pointers:
> template tmp(T:T*) {...}
> 

Yup, it's pretty much the same concept as C++.

Speaking about the doc, the "Specialization" section should appear sooner, since there are many references to specialization before its section. Also, on point 2 of Argument Deduction:
"2. If the type specialization is dependent on a type parameter, the type of ... " is a bit ambiguous IMO on the "dependent on a type parameter" part, as it is not clear that such depended type parameter must be the respective parameter of *that specialization*, and not any other type parameter of the template. It's the difference between these two cases:

  T : T*
  T : U*


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
1 2 3 4 5 6 7 8 9 10
Next ›   Last »