"dup" and "idup" actually *do* something. They shouldn't be properties, since they don't emulate a sealed attribute.
There! I said it. It is now filed.
The new property rules should allow us to make this change, and it shouldn't be breaking any code either.
Comment #1 by issues.dlang — 2014-04-24T21:06:24Z
Agreed. Properties are supposed to emulate variables. That's the whole idea behind them. dup and idup don't fit that bill at all. They're clearly functions, and if you want to still call them without parens, well empty parens are optional, so you can.
Comment #2 by zorael — 2014-04-26T16:49:04Z
It's semantically ambiguous as duplicate can be both a noun and a verb.
I tend to think of .{i,}dup the noun way; something.duplicateOf; where whether the .duplicateOf property "does" something or not remains up to implementation.
In abstract: the clerk has a stack of foos and you're asking for a .dup copy, so he fetches one from the pile and hands it to you.
The opposite is naturally .duplicateThisForMe, from which perspective they shouldn't be property functions, no.
Comment #3 by dkorpel — 2022-01-25T11:11:26Z
dup is now an implicitly imported function in druntime, does that fix this issue? Or do you want the specification to call them something different? In that case, the same should be done for associative array properties like .byKey and .rehash.
Comment #4 by robert.schadek — 2024-12-07T13:33:44Z