Antti Sykari <jsykari@gamma.hut.fi> wrote in news:87n0kebvdg.fsf_-_@hoastest1-8c.hoasnet.inet.fi:

> The best situation would be if there would be no need for such advice. Delegates can be made safe in different ways, some of which are:

7. Marking functions that will hold a reference.

void delagate() foo;

// stored flag marks fn as a as being
// stored by the function
void setFn(stored void deligate() a)
{
  foo = a;
}

void one()
{
  // Global scope
}

void bar()
{
  int i;

  void two()
  {
    // Does not access local scope
  }

  void three()
  {
    // Accesses local scope
    i = 5;
  }

  setFn(&one); // Ok
  setFn(&two); // Ok
  setFn(&three); // Error
}

Could be used for auto objects too

void foo(stored Object a)
{
}

void bar()
{
  auto Object o = new Object();

  foo(o); // Error
}

"Walter" <walter@digitalmars.com> wrote in message news:b3mnhp$26ii$1@digitaldaemon.com...
> > So "static" is being ignored.  Now would be a good time to move to "private" to mean the same thing instead,
>
> It already does.
>
> > and to make applying "static"
> > to a symbol at the module level an error.
>
> At the moment, it's a no-op.

Will this no-op change to "done"?

I do not like too much when one has more options to do
 the same. There are already two ways how to define arrays:
 C/C++ style and the new style - used also by eg C#.

I'm also confused with the fucntion literal declaration.
 Grammar states:
FunctionLiteral ::= function Type ( ParameterDeclarations )
 but the example just below goes like:
int function(char c) fp;
 instead of:
function int(char c) fp;

Is this intentional ambiguity? Or does it have some meaning
 unknown to me?

I'm also playing with the idea that the return type of a function
 should be always explicitly stated - to enforce this by grammar.
 I have two reasons:
a) looks beter
b) your default is void (contrary to int in C/C++)

These ambiguities at such a low level have some *bad*
 conssequences:
a) one need to learne them, that there are more ways to achieve
 exaclty the same and less readable code thereof
b) tool implementations will be more comlicated because of this
 (and reason? good feel only ... because it doe not add any new
 functionality)
c) it makes seraching in the source code more complicated
 (transition to more complicated regular expressions)

I do not know how other guys think about this, may be I'm
 alone who minds it  :)

"Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:b3rerf$2hdt$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message
news:b3mnhp$26ii$1@digitaldaemon.com...
> > > So "static" is being ignored.  Now would be a good time to move to "private" to mean the same thing instead,
> > It already does.
> > > and to make applying "static"
> > > to a symbol at the module level an error.
> > At the moment, it's a no-op.
> Will this no-op change to "done"?

?. no-op means "it's ignored".

> I'm also confused with the fucntion literal declaration.
>  Grammar states:
> FunctionLiteral ::= function Type ( ParameterDeclarations )
>  but the example just below goes like:
> int function(char c) fp;

That is not a function literal, but a declaration of a pointer to a function.

>  instead of:
> function int(char c) fp;

That is invalid.

> I'm also playing with the idea that the return type of a function
>  should be always explicitly stated - to enforce this by grammar.
>  I have two reasons:
> a) looks beter
> b) your default is void (contrary to int in C/C++)

The default isn't int in C/C++ anymore, it must be specified.

> These ambiguities at such a low level have some *bad*
>  conssequences:
> a) one need to learne them, that there are more ways to achieve
>  exaclty the same and less readable code thereof
> b) tool implementations will be more comlicated because of this
>  (and reason? good feel only ... because it doe not add any new
>  functionality)
> c) it makes seraching in the source code more complicated
>  (transition to more complicated regular expressions)
> I do not know how other guys think about this, may be I'm
>  alone who minds it  :)

I did it that way because the function literal syntax was already rather longish.

"Walter" <walter@digitalmars.com> wrote in message news:b3rhmu$2iju$1@digitaldaemon.com...
>
> > I'm also confused with the fucntion literal declaration.
> >  Grammar states:
> > FunctionLiteral ::= function Type ( ParameterDeclarations )
> >  but the example just below goes like:
> > int function(char c) fp;
>
> That is not a function literal, but a declaration of a pointer to a function.
>
> >  instead of:
> > function int(char c) fp;
>
> That is invalid.
>
> I did it that way because the function literal syntax was already rather longish.

Got it! Thanks.

A funny thought crossed my mind...

Are structs now equivalent to classes in the sense that struct member functions can be stored into delegates?  (They would, usually, be local delegates in the sense that structs tend to be stack-allocated.)

Should they?

-Antti

You're right... and you can't mark a user-defined cast as "explicit".  I'd much rather have just constructors.  Problem is, you can't add constructors to other classes such as "int".

Sean

> c) overloadable operators are a questionable syntactic-sugar feature of
C++.
> Overloadable type-cast operators are a nightmare, since the implicit type casts they cause go against all type safety principles

This requires multiple modules:

f.d:
   module foo.bar;
   import g;

g.d:
   import f;

Using "dmd f.d" complains that "g.d(1): module f is in multiple packages foo.bar".

Secondly, you say that you made "private" mean "static", but that doesn't work either:

f.d:
   import g;

   void main()
   {
      int x = foo;
   }

g.d:
   private int foo;

Using "dmd -c f.d" on this code compiles, even though it's an error.

Here's a symbol bug:

   class A
   {
      class Child
      {
      }
   }

   class B
   {
      class Child
      {
         static int value;
      }
   }

   void main()
   {
      printf ("%d\n", B.Child.value);
   }

Compiling this with "dmd module.d", I get "module.d(18): no property 'value' for type 'Child'".  A and B have nested classes with the same name, but B.Child resolves to A.Child.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b3sc9l$2uvl$1@digitaldaemon.com...
> You're right... and you can't mark a user-defined cast as "explicit".  I'd much rather have just constructors.  Problem is, you can't add
constructors
> to other classes such as "int".
>

To me, a need for "explicit" is just a sign that there is something inherently wrong with the 'feature' of implicit object creation when a single-argument constructor exists. Consider a function

void f( SomeClass c )

That means, that c needs to be of type 'SomeClass' (or a subclass of that). C++ actually allows you to have another class with a 1-argument constructor

class CompletelyDifferentClass
{
    CompletelyDifferentClass( SomeClass c )    // 1-argument constructor
}

and then (perhaps even depending on visiblity, I'm not sure here, and also if SomeClass is not abstract) you can do

CompletelyDifferentClass d;
f( d )

Reading this code without the class or function declarations would make you think that either (1) f takes a 'CompletelyDifferentClass' as an argument, or (2) a superclass thereof. Instead, _implicitly_ a new, temporary object of class SomeClass is created, using the 1-argument constructor. Horror! No reference to 'SomeClass' is made in the above code fragment, yet it is involved. So this means that a 1-argument constructor models "is_a" (while in fact it is "can_be_constructed_from_a")

I vote for explicit object construction always, preferrably with always the same language construct ("new" will do fine).

PS Following this line of thought, the C# feature of "boxing" does not appeal to me either. They claim that "everything is an object" (Marketing: "much better than Java"), but underwater some things are more object than others, heavily affecting performance as a "side effect"

"Jeroen van Bemmel" <anonymous@somewhere.com> writes:

> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b3sc9l$2uvl$1@digitaldaemon.com...
>> You're right... and you can't mark a user-defined cast as "explicit".  I'd much rather have just constructors.  Problem is, you can't add
> constructors
>> to other classes such as "int".
>>
>
> To me, a need for "explicit" is just a sign that there is something inherently wrong with the 'feature' of implicit object creation when a single-argument constructor exists. Consider a function
>
> void f( SomeClass c )
>
> That means, that c needs to be of type 'SomeClass' (or a subclass of that). C++ actually allows you to have another class with a 1-argument constructor
>
> class CompletelyDifferentClass
> {
>     CompletelyDifferentClass( SomeClass c )    // 1-argument constructor
> }
You probably meant vice versa:

class SomeClass
{
    SomeClass( CompletelyDifferentClass c );
}

> and then (perhaps even depending on visiblity, I'm not sure here, and also if SomeClass is not abstract) you can do
>
> CompletelyDifferentClass d;
> f( d )

Could be useful, if, for example, SomeClass is replaced by "int" and CompletelyDifferentClass with "float".  Sprinkling the code with explicit conversion function calls may make it less readable and make it more difficult to spot the "really dangerous" explicit conversions from the code.

-Antti