Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
if a function's argument is const ref, what would be the problem
of allowing it to to be passed const ref lvalues + rvalues?
I have this structure:
struct Scene
{
Array!Surface objects; // objects in the scene
Array!Light lights; // lights in the scene
/*private*/ BVHNode root; // root node of the BVH
tree
@disable this(); // disable the def
From Jonathan M Davis:
"...At this point, I don't think that the situation with default
constructors and
structs is going to change. It's a result of requiring init
properties for all
types, and is thus a "forced fault" in the language..."
Why does requiring init properties for all types resu
Why is it required to have the .init property? Where is it useful
and why was this decision made?
On Wednesday, 23 January 2013 at 12:07:48 UTC, monarch_dodra
wrote:
On Wednesday, 23 January 2013 at 11:03:45 UTC, Minas Mina wrote:
Why is it required to have the .init property? Where is it
useful and why was this decision made?
.init is very useful in the sense that it represents the raw
f = g; where it means f(g) is really ugly. I wouldn't like to see
this.
Also:
void printSomeStuff()
{
//...
}
We are going to see code like this:
printSomeStuff; // i think that's ugly.
I suggested make parentheses optional only for UFC syntax.
Also isn't it possible to allow @property for
On Friday, 25 January 2013 at 22:00:02 UTC, Rob T wrote:
Finally there are editors, and IDE's with decent D support. In
fact I find that C++ IDE and editor support is no better, and
fails often due to the near impossible nature of correctly
parsing through C++ code.
--rt
Come on, Visual C+
My opinion is to allow calling a function without parentheses
only in UFCS (properties must be called without). Is that so hard
to implement?
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
Ok, We have 2 usages of ref : when you actually need to modify
informations, and for performance reasons. Let's talk about the
second one.
Passing by ref to improve performance is not ideal. First this
is quite hard to know when it
@nogc sounds nice, but how could someone use classes(OOP) with
this?
On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut
wrote:
Am 19.02.2013 17:45, schrieb Minas Mina:
@nogc sounds nice, but how could someone use classes(OOP) with
this?
The same way you do in c++. Manual memory management.
But I guess you would like to have OOP as well. Would that
A big problem is that GDC and LDC in the distros are not up to
date. GDC was 2.058 I think. This has forced me to use dmd even
for my final code (I don't want to get in the trouble of building
them by source, this is ancient).
On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
Thanks for the input - but where is SafeD defined? Is there
a compiler switch?
I haven't looked at D in a while, it was just too big for ARM
Cortex M, smaller PowerPC and similar targets - a google search
got me to the SafeD topic.
N
You can use my raytracing in D project.
https://github.com/minas1/D_Raytracing
It's very incomplete at the current state by the way (no soft
shadows, no texturing, no reflection, no antialiasing).
On Friday, 22 March 2013 at 17:32:19 UTC, Kagamin wrote:
It's also somewhat wrong to pair D with C++. C++ can't bring
anything new to JVM because as a language it's not more
powerful than Java, ...
What? That's clearly wrong. C++ is far more powerful than Java.
One example is templates - java
Consider:
uint u = ...;
int x = u;
Wouldn't a warning be enough?
On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote:
And to pull the reverse: Why should '@val ref' be more
intuitive than ref&? Or why should be '@ref' more intuitive?
What I mean by that:
Both the Property as well as the hybrid path have their
weaknesses and are not necessarily immedi
Personally yes, I prefer @ref more. But you are right that it's
not nice to be an annotation.
I agree that language support for disabling the GC should exist.
D, as I understand, is targeting C++ programmers (primarily).
Those people are concerned about performance. If D as a systems
programming language, can't deliver that, they aren't going to
use it just because it has better templat
On Monday, 8 April 2013 at 13:01:18 UTC, Regan Heath wrote:
I've always hated the fact that C++ has 2 memory models
new/delete and malloc/free and I've never liked new/delete
because it doesn't allow anything like realloc - why can't I
reallocate an array of char or wchar_t??
Try using mal
Sorry, if it wasn't clear. I was talking about C++.
Even if you are not mixing the two, you can still get f*** up.
struct S
{
S()
{
cout << "S()\n";
}
};
int main()
{
S *s = new S(); // constructor is called
S *s2 = (S*)malloc(siz
I hope this proposal gets implemented soon :)
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu
wrote:
On 4/10/13 7:30 AM, Manu wrote:
The _problem_ is that functions are virtual by
default. It's a trivial problem to solve, however it's a major
breaking
change, so it will never happen.
I agree. We may as well save our bre
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu
wrote:
On 4/10/13 7:30 AM, Manu wrote:
The _problem_ is that functions are virtual by
default. It's a trivial problem to solve, however it's a major
breaking
change, so it will never happen.
I agree. We may as well save our bre
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu
wrote:
On 4/10/13 7:30 AM, Manu wrote:
The _problem_ is that functions are virtual by
default. It's a trivial problem to solve, however it's a major
breaking
change, so it will never happen.
I agree. We may as well save our bre
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu
wrote:
On 4/10/13 7:30 AM, Manu wrote:
The _problem_ is that functions are virtual by
default. It's a trivial problem to solve, however it's a major
breaking
change, so it will never happen.
I agree. We may as well save our bre
Yes, please do attribute inference!
On Wednesday, 17 April 2013 at 17:50:07 UTC, Namespace wrote:
Thanks to Kenji there is now a corresponding pull request:
https://github.com/D-Programming-Language/dmd/pull/1903
Let us hope that it will be quickly merged.
I still hope that Andrei or Walter say something to this topic.
Maybe we h
On Wednesday, 17 April 2013 at 19:29:51 UTC, Namespace wrote:
Finally, I'm tired of copy-pasting the same code just to
change to "ref". :)
What do you mean?
This:
/// dot product of two Vector3 vectors
auto dot(T) (Vector3!T u, Vector3!T v) @safe pure nothrow
{
return u.x * v.x + u.y
On Saturday, 20 April 2013 at 15:23:35 UTC, deadalnix wrote:
On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote:
I don't think adding more to the language is the sane thing
to do right now.
Why not? Could you explain this?
This issue is discussed since more than a year and it is a
ve
The only thing Java is good for is portability. And its standard
library is very good too.
However the language as it is, really sucks in my opinion. I
mean, there's no way to change the value of a primitive type
passed to a method? Come on.
On Tuesday, 7 August 2012 at 00:12:55 UTC, Alex Rønne Petersen
wrote:
Hi,
Has anyone managed to get the 2.060 .deb working on Ubuntu
12.04? On all 12.04 systems I have access to, all D programs
consistently segmentation fault in gc_init().
I have dmd64 on ubuntu 12.04 64 bit, and it works fi
I have written a function that returns the number of unique
elements in an input range (along with some unittests), and put
it in std.algorithm.
I have also made a pull request for it.
Is it considered useful to be an addition to phobos?
Can someone review it?
Thanks
1) I think compile-time function execution is a very big plus for
people doing calculations.
For example:
ulong fibonacci(ulong n) { }
static x = fibonacci(50); // calculated at compile time! runtime
cost = 0 !!!
2) It has support for a BigInt structure in its standard library
(which
I'm writing an insert() function for a binary tree in D:
Note: Node is a value type (struct)
Node!(T)* insert(T) (Node!(T)* root, T val)
{
if( root is null )
{
root = new Node!T();
root.value = val;
root.left = root.right = null;
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
On 4/25/2013 10:49 PM, Ali Çehreli wrote:
It certainly behaves that way but it isn't an integer type and
that's why it is
unintuitive.
But it is an integer type.
It is an integral type _internally_.
A bool type should have the v
On Saturday, 27 April 2013 at 11:41:30 UTC, kenji hara wrote:
First, I can guess that why Walter disagree *fixing* this
problem.
http://dlang.org/overview.html
Major Design Goals of D
9. Where D code looks the same as C code, have it either
behave the same
or issue an error.
C doesn't hav
VRP is only useful when doing this:
short s = 1000; // 1000 is int, but it's safe to put it into a
short
Integers are not booleans. I agree with the others that bool
being treated as an int is an implementation detail derived from
C.
Or are you just bored for doing:
if( x == 0 )
instead o
On Sunday, 28 April 2013 at 22:40:33 UTC, Andrei Alexandrescu
wrote:
On 4/28/13 5:41 PM, kenji hara wrote:
Yes, as Andrei mentioned, it is sometimes useful. But, at
least during
overload resolution, it must not occur.
Kenji Hara
Well the problem has other ramifications beyond bool. Consider:
I agree that checks for overflow should exist in debug builds
(and not exist in release builds).
On Sunday, 19 May 2013 at 18:30:09 UTC, deadalnix wrote:
void buzz(Foo f) {
f.foo(); // Rely in faith. It is invalid and way easier to
write than the valid code, which is THE recipe for it to spread.
}
Shouldn't this throw a NullPointerSomething?
I don't think this is useful.
At least when I see "auto" in the code I immediately understand
what's going on, whereas with this proposal I have to double
check my code to see if it's ":=" or "=".
On Tuesday, 28 July 2015 at 19:30:45 UTC, Jonathan M Davis wrote:
And his scoring system is going to put most projects into fail
territory _very_ quickly.
An interesting read though.
- Jonathan M Davis
Because most project fail?
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
D is really cool and makes a good candidate for developing a
game. Are there any guys out there using D for indie games?
For some time I have been seeing some cool game engine
On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland wrote:
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
D is really cool and makes a good candidate for developing a
game. Are there any guys out there using D for in
On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis
wrote:
Ultimately, I think that we're better off with TDPL's
definition of synchronized classes than the synchronized
functions that we have now, so I do think that
On Wednesday, 18 November 2015 at 05:49:00 UTC, tcak wrote:
On Tuesday, 17 November 2015 at 19:32:05 UTC, Adam D. Ruppe
wrote:
On Tuesday, 17 November 2015 at 19:27:15 UTC, tcak wrote:
As far as I know, GC has a separate thread that stops all
other threads periodically to clear the unused memor
SDLang is fine. If someone wants to use D, it won't be SDLang
that will stop him.
Keep calm and use SDLang.
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Thursday, 3 December 2015 at 22:54:53 UTC, Andrei Alexandrescu
wrote:
Nothing. But one thing I was keeping an eye for would be to
allow lst.stable.linear.xxx and lst.linear.stable.xxx with one
body. -- Andrei
Please don't. Choose one to be the outer and one to be the inner.
Otherwise peopl
On Friday, 4 December 2015 at 03:46:39 UTC, Walter Bright wrote:
On 12/3/2015 5:27 PM, Andrei Alexandrescu wrote:
Now this primitive may have three complexities:
* linear in the length of r (e.g. c is a singly-linked list)
* linear in the number of elements after r in the collection
(e.g. c i
On Friday, 4 December 2015 at 22:48:03 UTC, Andrei Alexandrescu
wrote:
On 12/04/2015 03:43 PM, Walter Bright wrote:
On 12/4/2015 10:49 AM, Dmitry Olshansky wrote:
Was vaguely terrified reading this whole thread until hitting
this
gem. Seems
like a creative use for UDA.
Yeah, I think it puts
On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh
wrote:
On 26/01/16 11:33, deadalnix wrote:
On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim
Grøstad wrote:
[...]
Now if one want to use that, D is very capable of doing it
already. Just
won't make it the default (like it is
On Wednesday, 3 February 2016 at 18:04:38 UTC, Andrei
Alexandrescu wrote:
On 02/03/2016 10:05 AM, Sönke Ludwig wrote:
For std.move, isn't the only place where an exception can be
thrown in
the destructor (which shouldn't throw)? It uses memcpy to move
the
memory around to circumvent any extend
On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
Motivated by Dmitry's "Pitching D to a gang of Gophers" thread,
how about pitching it to a gang of professors and graduate
students?
I will be presenting D to such an audience at METU in Ankara.
What are the points that you would str
On Tuesday, 8 March 2016 at 17:31:58 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 8 March 2016 at 15:54:46 UTC, Dmitry Olshansky
wrote:
This more or less means that we (as in D enthusiasts) have
some more time to carve up some "market" share. Till C++20 I
guess.
Yes, but they got in parallelis
On Tuesday, 8 March 2016 at 22:53:01 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 8 March 2016 at 18:24:54 UTC, Minas Mina wrote:
I honestly don't care about those. Boost has them. Modules are
far more important for me.
Just found out that Modules weren't supposed to be scheduled
On Tuesday, 19 April 2016 at 22:28:27 UTC, Alex Parrill wrote:
I'm proposing that std.experimental.allocator.make, as well as
its friends, throw an exception when the allocator cannot
satisfy a request instead of returning null.
[...]
I believe it was designed this way so that it can be used
On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 03:39 PM, Dmitry Olshansky wrote:
On 27-May-2016 21:11, Andrei Alexandrescu wrote:
On 5/27/16 10:15 AM, Chris wrote:
It has happened to me that characters like "é" return length
== 2
Would normalization make len
On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 03:39 PM, Dmitry Olshansky wrote:
On 27-May-2016 21:11, Andrei Alexandrescu wrote:
On 5/27/16 10:15 AM, Chris wrote:
It has happened to me that characters like "é" return length
== 2
Would normalization make len
On Sunday, 23 October 2016 at 13:04:30 UTC, Stefam Koch wrote:
Hi Guys,
while brushing up on my C and algorithm skills, accidently
created a version of fibbonaci which I deem to be faster then
the other ones floating around.
It's also more concise
the code is :
int computeFib(int n)
{
62 matches
Mail list logo
