Sean Kelly wrote:
> == Quote from Scott S. McCoy (tag@cpan.org)'s article
>> On Wed, 2008-04-16 at 22:01 -0400, Jason House wrote:
>>>> Remove the implicit "length" inside slice brackets as it conflicts
>>> with
>>>> outer length. Allow only $.
>> The conflict is irrelevant.  I vote +1 for ditching "length" as a
>> magical keyword inside a slice index.
>> Although I still wish we had [..], [0..] [..N]... :-)
> 
> That reminds me... drop the dual meaning of "auto".  The old meaning
> has hung on for far too long.
> 
> 
> Sean

That's another really good one. Especially with other storage classes, it can be a real killer when "const auto S = ...;" doesn't mean the same thing as "const S = ...;".

Robert Fraser wrote:
> Christopher Wright wrote:
>> Robert Fraser wrote:
>>> 2. Allow interfaces that are not sub-interfaces of IUnknown to be explicitly "delete"d.
>>
>> Just make all interface variables implicitly typed Object as well. Or make an IObject interface that Object and all interfaces inherit from, then make delete take an IObject as well.
>>
>> Then you can have IUnknown not inherit from IObject if you want.
>
> Yup, that's how it should be implemented. Unless you're suggesting make users rewrite all their code so that their interfaces extend IObject, in which case I object. (that was kind of lame)
Also, to add to Robert's post - This also applies to classes:
if you define the IObject interface all classes would inherit from it
and would have to provide implementation for it instead of just
inheriting the implementation from Object.
the best solution for this IMO is Christopher's first idea - make all
interfaces subtypes of object.
-- Yigal

On Thu, 17 Apr 2008 18:33:35 +0400, Sean Kelly <sean@invisibleduck.org> wrote:
> [snip]
> I'm not sure it's sufficiently simple, but a while back I suggested making
> constructors inherited by default.  Here's the link:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Inheriting_constructors_54088.html
>
> For simple stuff, I'd like to see opEquals return a bool if it doesn't already
> in D 2.0.  Also, I'd like closures to be given some attention.  Currently, they
> seem to allocate too often for non-escaping closures.  This needs to be
> looked at and if syntax must be added to override the automatic allocation
> then it should be done sooner than later.
>
>
> Sean

Hey, good idea! And the feature gets its way to C++0x, too, but not implicitly:
(example from wikipedia)

class BaseClass
{
public:
  BaseClass(int iValue);
};

class DerivedClass : public BaseClass
{
public:
  using default BaseClass;
// same as
//  DerivedClass(int iValue) : BaseClass(iValue) {}
};

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

e-t172 wrote:
> Robert Fraser a écrit :
>> The only time I've run into the problem is in array declarations, but I know it's also a problem for template metaprogramming. An example of the array thing is declaring a literal array of strings:
>>
>> auto cities = [ "New York", "London", "Paris", "Tokyo" ]
> 
> It will compile if you replace "auto" by "char[][]":
> 
> char[][] cities = [ "New York", "London", "Paris", "Tokyo" ];
> 
> This solves the problem, I guess, because the "char[][]" removes the static/dynamic array ambiguity.

a reason auto is bad :)
ambiguity is the program killer