www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Compiler fails to identify conflict when using array parameters

reply "Kris" <fu bar.com> writes:
Conflict reported:

class Foo
{
        void foo (int i) {}
        void foo (int i) {}
}

No conflict reported:

class Foo
{
        void foo (char[] i) {}
        void foo (char[] i) {}
}
Dec 23 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Kris wrote:

 Conflict reported:

 No conflict reported:

For a practical programmer the second case is not a problem because the conflict is reported as soon as the function is called, which is most likeley done in the `unittest'. This is also consistent with the behaviour of not reporting conflicting definitions from imports until they are used. Therefore only an irregularity can be found in the first case. But it is surely not a bug to report conflicts earlier than usual. -manfred
Dec 23 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Manfred Nowak wrote:
<snip>
 This is also consistent with the behaviour of not reporting 
 conflicting definitions from imports until they are used.

That's different. Conflicting function names in different libraries are not a fault of either library. It is the responsibility of the app programmer to disambiguate between them. OTOH there is no possible way to disambiguate between the two functions in the OP's case. As such, it is an error in the module in which the functions are defined. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on on the 'group where everyone may benefit.
Dec 24 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Stewart Gordon wrote:

[...]
 OTOH there is no possible way to disambiguate between the two
 functions in the OP's case.  As such, it is an error in the
 module in which the functions are defined.

Thanks for your input. It changed my view on the subject drastically. Your argument is true and well founded under the assumption, that declarations should enable usage. But if you drop this assumption it is becoming wrong. i.e. if you want a way to prohibit the usage of an identifier you are loosing a simple way, when double declarations are errored out by the compiler if in the same module. For example look at the topic "Can I stop people deriving from my class?" in Stroustrups FAQ http://public.research.att.com/~bs/bs_faq2.html Wouldn't it be neat to simply declare the constructor of class `Usable' twice? -manfred [X-posted and F'up to Digitalmars.D]
Dec 24 2005
prev sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kris schrieb am 2005-12-23:
 Conflict reported:

 class Foo
 {
         void foo (int i) {}
         void foo (int i) {}
 }

 No conflict reported:

 class Foo
 {
         void foo (char[] i) {}
         void foo (char[] i) {}
 }

At first it seemed like a no-brainer, but D certanly has some interresting properties. is legal: # module some_module; # class A{} # struct A{} # enum A{ DUMMY } is discurraged: (statement.html: Local names should all be unique within a function.) # void someFunction(){ # class A{} # struct A{} # enum A{ DUMMY } # } Either my understanding of D's name spaces is severly lacking or the docs seem to be inconsistend. By the way why "*should* be unique" and not "have to be unique"? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDsuhG3w+/yD4P9tIRAjyqAJ44MElEnU3OwZfPFKPdqN2noAZzmgCgogVj 5FwsNqLCgpkh87ocPSjUP9o= =2kjj -----END PGP SIGNATURE-----
Dec 28 2005