Preferred Order Of Src Dst Arguments

The RightThing is of course to limit all functions to one argument, and use CurryingSchonfinkelling for the rest of the parameters. For some reason, however, this suggestion isn't a very popular one... ;) - JayOsako

I was just typing in this copy function: 

 template <class T> void CopyImageAndDisplay?(T *dstAcuObj, T *srcAcuObj)
and I realized that I reflexively put the destination argument first. I started wondering why I did that. Probably a habit formed by years of programming C/C++ and x86 assembly. I got curious and did a quick non representative scan through the MSDN library. I expected that something designed from the ground up (Java) would have some kind of convention but it doesn't seem like it. It's kind of hard to tell because OO tends to use Obj.Copy(src), which I can't do with my template function.

So, to satisfy my curiosity, can someone point me to a poll or some stats or, better yet, does someone have the definitive answer?

AndrewQueisser

I suppose I would do it instead like this: 

 destImage = srcImage.copy();
 destImage.display( dispCtx );
Or some variation of that. -- RobertDiFalco

Nope, but if I wanted to bluff, I might start with 

 dest = src;
If you really had to keep the 2-argument function, you could at least catch some common mistakes up-front with: 
 void CopyImageAndDisplay?(T *dstAcuObj, const T *srcAcuObj)
--RickSamuels

On the other hand, in assembly language and in machine code, the destination is (always ?) specified after the source (when they occur in different instructions): 

 src @ dest ! \ in the ForthLanguage
. When different source and destination arguments occur in the same assembly language instruction, some assemblers put the source first, others put the destination first, which assembly language programmers find endlessly confusing when they start using a different processor. (I've heard some people talk about Intel order vs. Motorola order, from the traditional assemblers for x86 vs. 680x0 processors).

For example,

most assemblers for the 680x0 allow you to write 

    move.b 7, d0 ; move 7 into d0
most assemblers for the 80x86 allow you to write 
    mov    al, 7 ; set al to 7
although the AT&T assembler for the 80x86 has the arguments swapped the other way around.

AssemblyLanguage calls the 2 possible orderings "Intel style" vs. "AT&T style".

Using "x86 vs. 68k" in this sense, though, can be confused with another sense - x86 chips are LittleEndian while 68k chips are BigEndian.

Most command line programs (for UNIX, DOS, and Windows) are of the form "mv src dst", mainly because you might want to do "mv src1 src2 src3 dst/" instead.

Linguistically, the object that changes (the destination object) is often the "primary actor" of the sentence, and thus it makes sense to put it first. Kind of akin to most languages putting the object first in imperative clauses, followed by adverbials. This kind of emphasis is demostrated by both 

 obj.add_listener(listener)
and 

 fprintf(stderr, "%s to your %s", swearwords[errno], argv[0]);
When designing function or method signatures, I always prefer to put destinations before sources, mimicking assignment and following (I think) long years of tradition. (Examples: strcpy in C, rplaca in ancient Lisp, DAXPY in the BLAS. Counterexample: copy in the C++ standard library.) The first few assemblers I used followed the same convention, so I find the reverse uncomfortable; oddly enough the Unix mv command doesn't bother me at all. I think assemblers should adopt syntax that makes the direction of assignment explicit: perhals "mov al <- 7" versus "mov 7 -> al", etc. I believe Intel's assembler for Itanium does something like this. -- GarethMcCaughan

Yes, I often wish for a slighly improved assembly language. Should we collect ideas on a wiki page -- is BetterAssembly? a good name ? ... -- DavidCary

PL360 (one of the WirthLanguages) is a good example of a structured assembly language. See Wirth's technical report available here:

Whenever I'm writing code in ObjectiveCaml, I try to put my destinations first... because OCaml allows partially-applied functions, which I can then pass to iterators more easily. 

  let foo src dest = ... in
  List.iter (fun x -> foo x somecollection) somelist
becomes 
  let foo dest src = ... in
  List.iter (foo somecollection) somelist
The expression (foo somecollection) returns a new function which takes one argument, which happens to be the source. It really doesn't change the semantics I suppose, and could be argued to be less clear (I don't think it is), but is nicer to write.

And now for something completely different: http://www.haskell.org/ghc/docs/edison/users004.html#toc10

Whenever a function takes multiple arguments, there is a choice as to the order of the arguments. I have tried to make these choices according to the following rules, in decreasing order of importance:

perhaps related to WhyIsTheFirstArgSpecial ?

EditText of this page (last edited November 13, 2014) or FindPage with title or text search