Permalink
Reply
On Saturday, 5 April 2025 at 21:39:01 UTC, Paul Backus wrote:
>Not everyone will use opNew either. If you are capable of achieving uniformity with opNew, you are also capable of achieving uniformity without it.
Like I said, we can try to convince everyone to use 'make' as the one and only synonym for 'new', but when you offer an operator overload with nicer syntax, people naturally gravitate towards that. I've never seen someone create an array that you have to index with array.index(i) in D.
In any case, "writing parentheses is annoying sometimes" is kind of a weak justification for introducing new syntax.
Huh? Making code nicer to read/write is the whole point of syntax. It's why Lisp has its reputation, and why D allows make!T instead of make!(T), and why some propose to make parentheses around if conditions optional.
I cannot think of a single situation where I've been reading D code and felt the need to "easily locate creation of objects."
That's understandable, many programmers don't (need to) care where memory allocations happen.
>I have been in situations where I wanted to know where a specific object was being created, and grepped for new T to find it--but I could have grepped for make!T just as easily.
But would someone who doesn't know about all the allocator libraries in use by a project know to include make!T in their search, as well as alloc!T etc.?
>So, let me get this straight: you're proposing that myAllocator.new ubyte[n] would (potentially) return some custom library type, instead of a ubyte[]?
No, not at all. opNew should always return the same type as the equivalent new expression, I should probably add to the DIP that the compiler verifies that.
To illustrate what I'm talking about, here's the actual git history of a line of code in an OpenGL application of mine:
lightBias = newArrayMalloced!float(w * h);
lightBias = newArrayM!float(w * h);
lightBias = allocator.array!float(w * h);
lightBias = new float[](w * h);
You can tell I've been struggling with my memory allocator APIs. However, I've never struggled with the API for my custom allocator-backed array types, because opIndex and opBinaryAssign!"~" are the obvious choice which make refactoring from int[] to Array!int easy. Had opNew existed, I would have used that from the start and be content with it.
Yes, this might just be a very 'me' problem. And again, it's no big deal to rename newArrayMalloced to newArrayM in 35 places. I just thought this DIP could be a little nicety, filling a small hole in D's operator overloading story. I posted this DIP here to poll if anyone else is interested in this.
