From -3788421209111072316 X-Google-Thread: 7894ca11fe,ad25a0efe0463aca X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.glorb.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: Sean Hunt Newsgroups: comp.std.c++ Subject: Re: New range-based for and the creation of another kind of "magic" function Date: Mon, 3 Aug 2009 19:14:58 CST Organization: http://groups.google.com Lines: 76 Sender: cppmods@cs.rpi.edu Approved: austern@google.com Message-ID: References: <404cca88-36b3-4708-8748-8f15edac2ec4@a37g2000prf.googlegroups.com> NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=ISO-8859-1 To: (Usenet) Return-Path: X-Original-Date: Mon, 3 Aug 2009 16:11:22 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:1214 On Aug 3, 12:16 pm, Francis Glassborow wrote: > > Currently, C++ has a dearth of "magic" functions. These allow the C++ > > language to assign special properties to them that other functions do > > not have. There are four basic types of magic functions in the > > language: ::main(), constructors, destructors, and operator functions > > (While there are at least four different types of functions that are > > defined with the operator keyword, they can be grouped together for > > the purposes of this discussion). Every one of these functions is > > specified using a special syntax - there is no ability to mistake it > > for a "normal" function with no significance to the language. > > While I agree with you that ::main() is special (in that it cannot be > called and falling off the end of it is not an error) and ctors are > special (no return type) and dtors are somehow special because of the > way they chain together how are operator functions special? OK they have > two token names but, IMO, not much else is special about them. The compiler will perform special lookup on operator expressions that can look up operator functions, and they are restricted in the number of arguments they can have. There are some other special cases, too (conversion operators have no distinct return type). For the record, the four types of operators to which I was referring were "real" operators (those that overload built symbols), new/delete, conversion functions, and user-defined literal suffixes. I guess copy assignment operators could also be considered unique as they get implicit definition by the compiler. > > I will use the term "magic function" in the remainder of this post to > > refer to any function with special language-defined semantics that > > differ from ordinary functions, and "magic name" to refer to any name > > which, if a function has it, may result in the function being magic. > > OK, but I have always understood 'magic' to refer to an implementation > that cannot be written in C++ and so needs some under the cover action > by the implementation. I consider the term magic to also apply to something that is treated specially by the compiler - in this case, 'begin' and 'end' functions. > > The new range proposal creates a for loop with syntax "for (i : vec)" > > which will, for a vec of a user--defined type, cause an implicit > > lookup of begin(vec) and end(vec), but using only argument-dependent > > lookup - that is, only functions in the same namespace as vec will be > > considered. This makes begin and end into magic names - the first two > > such names in C++, other than ::main(). > > Your argument seems to be very convoluted. I wonder if you can rewrie it > focusing on the major issues. Basically, my issues are this: - We are adding function names that must be treated specially to avoid unwanted behavior - We are adding an element of the language that cannot be reproduced in language due to its odd lookup rules. This means you cannot, for instance, perform SFINAE on begin and end with 100% certainty, like you now can with every other function. - We are setting the precedent to possibly add more magic names, and these might not be backwards-compatible. - We are removing clarity from the language. - We are precluding a member implementation which, while not necessarily bad, may be confusing I think that every one of these can be solved by adopting a new function id, such as "operator begin" - several suggestions were at the bottom of the original post. Sean Hunt -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]