View mode: basic / threaded / horizontal-split · Log in · Help
July 25, 2006
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Next ›   Last »
6 7 8 9 10
Top | Discussion index | About this forum | D home