On 2015-06-11 14:33, Steven Schveighoffer wrote:
OK, I see the problem. When you type 'a.' then if you put up the list of
members and UFCS functions available, then that list may be huge (and
possibly filled with useless calls). That definitely is an issue.
However, I think DCD should still
On Thursday, 11 June 2015 at 12:33:55 UTC, Steven Schveighoffer
wrote:
On 6/10/15 8:52 AM, John Colvin wrote:
On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer
wrote:
On 6/9/15 4:06 AM, Brian Schott wrote:
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh
wrote:
Also, you
On 6/10/15 8:52 AM, John Colvin wrote:
On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer wrote:
On 6/9/15 4:06 AM, Brian Schott wrote:
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
Also, you say 5 seconds as if that's a short amount of time.
If it takes an
On Tuesday, 9 June 2015 at 16:01:34 UTC, Andrei Alexandrescu
wrote:
Same as with @safe @nogc @nothrow @pure.
No, these are attributes that change the function's type;
constexpr does not.
AIU, it still does something along those lines.
If you don't have ctfeability
expressed in function's
On 2015-06-10 01:02, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
I could, but D would not check it?
It could most likely be implemented with AST macros.
--
/Jacob Carlborg
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local variable diskIdx, and
they are confusing, what it has to do with UFCS?
auto diskIdx = data.diskIdx();
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote:
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local variable
diskIdx, and
they are confusing, what it has to do with UFCS?
auto diskIdx = data.diskIdx();
auto diskIdx1 = this.diskIdx;
On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer
wrote:
On 6/9/15 4:06 AM, Brian Schott wrote:
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
Also, you say 5 seconds as if that's a short amount of time.
If it takes an automatic scanner 5 seconds, it means the
On Wednesday, 10 June 2015 at 06:34:13 UTC, Shachar Shemesh wrote:
On 10/06/15 09:14, deadalnix wrote:
I do think you think at it the wrong way. people are not
telling you it
is bad code. You are telling us it is bad code (because you
mention
having problem that people using other style do
On Tuesday, 9 June 2015 at 23:11:35 UTC, Timon Gehr wrote:
enum ct(alias a)=a;
Thanks! I need to remember that enum means compile-time
constant and not strictly enumeration.
I guess one can use __ctfe to use a function at compile time and
a lut a runtime too, e.g. __ctfe ? sin(x) :
On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote:
On 10/06/15 15:37, Kagamin wrote:
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh
wrote:
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local variable
diskIdx, and
they are
On 10/06/15 17:05, Kagamin wrote:
On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote:
On 10/06/15 15:37, Kagamin wrote:
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote:
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local
On 10/06/15 15:37, Kagamin wrote:
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote:
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local variable diskIdx, and
they are confusing, what it has to do with UFCS?
auto diskIdx = data.diskIdx();
On Wednesday, 10 June 2015 at 05:31:18 UTC, Shachar Shemesh wrote:
On 10/06/15 00:29, Walter Bright wrote:
First off, D does not allow shadowing local variable
declarations.
Secondly, if you've got a lot of global variables, you've got
a program
design problem anyway. And lastly, naming
On 10/06/15 09:14, deadalnix wrote:
I do think you think at it the wrong way. people are not telling you it
is bad code. You are telling us it is bad code (because you mention
having problem that people using other style do not have).
It is not a problem in C++. It is not a problem with no
On Wednesday, 10 June 2015 at 01:28:40 UTC, Walter Bright wrote:
I'm bemused by the argument that D is deficient because it
doesn't implement a non-existent feature of C++.
I think you are offended ;^]. I have not said that D is deficient
regarding constexpr, I've suggested that I think D is
On 6/10/15 8:48 AM, Joakim wrote:
On Wednesday, 10 June 2015 at 15:12:47 UTC, ZombineDev wrote:
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical Specification,
and won't be ready on time for inclusion into ANSI C++ 17.
On 06/10/2015 11:12 AM, ZombineDev wrote:
Sorry, I couldn't resist to share this:
https://www.youtube.com/watch?v=ND-TuW0KIgg
Omg that's hilarious :)
On Wednesday, 10 June 2015 at 15:12:47 UTC, ZombineDev wrote:
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't be ready on time for inclusion into
ANSI C++ 17.
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't be ready on time for inclusion into
ANSI C++ 17.
https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
So, here
On 2015-06-09 11:33, Walter Bright wrote:
D's anti-hijacking lookup rules pretty much blunt this sort of problem.
Even though the compiler makes sure there's no ambiguity it might not
always be so easy to find the definition.
--
/Jacob Carlborg
On Tuesday, 9 June 2015 at 08:58:19 UTC, Shachar Shemesh wrote:
but:
@property void func( ref A a, int b ) ...
should work. Same goes for dropping the () to zero arguments
function calls. Once that needs to be a conscious decision by
the programmer, my problems with UFCS are greatly reduced
On Tuesday, 9 June 2015 at 08:57:58 UTC, Chris wrote:
On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote:
On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote:
On 6/8/2015 11:17 AM, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't
On 6/9/2015 12:42 AM, Shachar Shemesh wrote:
Ambiguity over location of definition is something that promotes bugs.
D's anti-hijacking lookup rules pretty much blunt this sort of problem.
On Tuesday, 9 June 2015 at 08:40:21 UTC, Shachar Shemesh wrote:
But that's just it. With UFCS, the function no longer needs to
be in the same module as the class/struct to which it is
referring. In fact, that is the whole point.
What you complain about again? C never had modules or whatever
On Tuesday, 9 June 2015 at 09:16:40 UTC, weaselcat wrote:
On Tuesday, 9 June 2015 at 08:57:58 UTC, Chris wrote:
On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote:
On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote:
On 6/8/2015 11:17 AM, Paulo Pinto wrote:
Apparently modules
On 09/06/15 10:21, Paulo Pinto wrote:
It is no different than extension methods in .NET, Ceylon, Kotlin,
multi-methods in CLOS or implicits in Scala.
I never could understand that line of reasoning:
Argument: So and so is bad because A
Answer: X, Y, and Z also do so and so
How is the answer
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote:
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote:
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to
unify the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by
allowing
On Tuesday, 9 June 2015 at 08:03:18 UTC, weaselcat wrote:
what would need to be done to get dscanner fit to be part of
the standard D tool chain?
We're starting with dfmt and dfix.
On Tuesday, 9 June 2015 at 07:42:40 UTC, Shachar Shemesh wrote:
Ambiguity over location of definition is something that
promotes bugs. The technical problem of finding the definition
is the least important aspect of the problem.
I don't understand the problem then: you're saying you have no
On Tuesday, 9 June 2015 at 07:59:41 UTC, weaselcat wrote:
simple solution:
just make everything a template, and alias empty-templated
functions ;)
also, AFAIK in 2.068 auto return functions are getting
attribute inference.
Templates don't help in meeting CTFE requirements.
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote:
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to unify
the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by
allowing
functions of either kind to be invoked by syntax of
On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu wrote:
On 6/8/15 1:25 PM, ponce wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time
code
looking like runtime code. But I never had the pleasure to use
On 06/09/2015 08:54 AM, Shachar Shemesh wrote:
It is one of the most confusing aspects of D. It makes it close to
impossible to locate the definition for a function used.
close to impossible? :o)
If you can find a.foo() and foo(a) without UFCS, then you can find them
with UFCS.
On Tuesday, 9 June 2015 at 07:58:04 UTC, Kagamin wrote:
On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu
wrote:
On 6/8/15 1:25 PM, ponce wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time
code
looking
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote:
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote:
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to
unify the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by
allowing
On Tuesday, 9 June 2015 at 08:33:04 UTC, Kagamin wrote:
Extension methods are conceptually the type's methods. The
type's interface is a conceptual thing, I don't think it has
anything to do with physical layout of source code.
This is a tricky issue. If you have structural typing (which
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
Also, you say 5 seconds as if that's a short amount of time.
If it takes an automatic scanner 5 seconds, it means the amount
of coverage it needs to perform is huge.
If anybody was wondering why DCD doesn't support UFCS, this is
On Tuesday, 9 June 2015 at 07:42:40 UTC, Shachar Shemesh wrote:
I use DCD, and *for the most part* it does a reasonable job of
finding the definition. It is not, however, something that
excuses a language feature that makes life more difficult.
Ambiguity over location of definition is
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
Please see my answer to Joakim. Also, you say 5 seconds as if
that's a short amount of time. If it takes an automatic scanner
5 seconds, it means the amount of coverage it needs to perform
is huge.
Probably a tooling issue, for
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
On 09/06/15 10:21, Paulo Pinto wrote:
It is no different than extension methods in .NET, Ceylon,
Kotlin,
multi-methods in CLOS or implicits in Scala.
I never could understand that line of reasoning:
Argument: So and so is bad
On 09/06/15 11:17, Kagamin wrote:
Not sure what you compare it to. Even finding declaration was never an
easy job in C, and definition can be anywhere in the source tree. In D
symbols are at least tied to modules, so you can look only in the
respective module, this never worked for C though.
On 09/06/15 11:35, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
I agree, I have conventions in my C++ code where member functions and
free functions shouldn't mix.
But given C++ templates lack of type safety, I'm not surprised that BS
pushes it. It also
On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote:
On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote:
On 6/8/2015 11:17 AM, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't be
ready on time for inclusion into ANSI C++ 17.
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case. See also the
related problem of guaranteeing that a template is
When constexpr is part of the prototype you know that it isn't
supposed to do substantial work.
Without it, you risk the
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe guarantee
at all. It just works.
On Tuesday, 9 June 2015 at 07:58:04 UTC, Kagamin wrote:
On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu
wrote:
On 6/8/15 1:25 PM, ponce wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time
code
looking
On Tuesday, 9 June 2015 at 09:06:38 UTC, Ola Fosheim Grøstad
wrote:
but a problem for structural/duck-like typing when you scale up.
Not a problem of cognitive complexity, though.
On Tuesday, 9 June 2015 at 10:16:12 UTC, Ola Fosheim Grøstad
wrote:
When reading code I don't want to wonder if
On Tuesday, 9 June 2015 at 09:33:33 UTC, Walter Bright wrote:
On 6/9/2015 12:42 AM, Shachar Shemesh wrote:
Ambiguity over location of definition is something that
promotes bugs.
D's anti-hijacking lookup rules pretty much blunt this sort of
problem.
It does not prevent programmers from
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote:
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to unify
the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by
allowing
functions of either kind to be invoked by syntax of
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote:
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to unify
the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by
allowing
functions of either kind to be invoked by syntax of
On Monday, 8 June 2015 at 22:17:34 UTC, Andrei Alexandrescu wrote:
On 6/8/15 12:48 PM, Paulo Pinto wrote:
I see a problem that having those features in C++ will reduce
the desire
from companies to adopt D.
At very least they should acknowledge all of you guys for the
ideas.
As I said at
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to unify the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing
functions of either kind to be invoked by syntax of either kind.
Dear god, I hope this doesn't pass.
It is one of the
On 09/06/15 10:27, Joakim wrote:
Perhaps Dscanner's declaration finder (the -d flag) or DCD would make
your life easier. I use Dscanner all the time and miss it when I'm
stuck with grep for C nowadays:
https://github.com/Hackerpilot/Dscanner
https://github.com/Hackerpilot/DCD
I use DCD, and
On 06/09/2015 02:28 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe
On Tuesday, 9 June 2015 at 11:39:49 UTC, Kagamin wrote:
Not sure how physical layout of source code affects
understanding of libraryobject.print().
One of the arguments for having separate declarations and
definitions in C++ is that it provides better encapsulation
(which C++ breaks for
On Tuesday, 9 June 2015 at 14:05:40 UTC, Ola Fosheim Grøstad
wrote:
One of the arguments for having separate declarations and
definitions in C++ is that it provides better encapsulation
(which C++ breaks for templates and inlined methods).
If you have full encapsulation you know that the
On Tuesday, 9 June 2015 at 15:06:13 UTC, Kagamin wrote:
Well, if you have full encapsulation, then you don't have
extension methods and consequently don't have this issue.
Well, you can, because you don't access object internals, but the
point was exactly that extension methods can make
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 6/9/15 12:58 AM, Kagamin wrote:
Same as with @safe @nogc @nothrow @pure.
No, these are attributes that change the function's type; constexpr does not.
Why is that better?
On 6/9/15 12:58 AM, Kagamin wrote:
On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu wrote:
On 6/8/15 1:25 PM, ponce wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time code
looking like runtime code. But
On Tuesday, 9 June 2015 at 15:49:07 UTC, Timon Gehr wrote:
On 06/09/2015 02:28 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this
On Tuesday, 9 June 2015 at 08:06:52 UTC, Brian Schott wrote:
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
Also, you say 5 seconds as if that's a short amount of time.
If it takes an automatic scanner 5 seconds, it means the amount
of coverage it needs to perform is huge.
If
On Tuesday, 9 June 2015 at 18:20:43 UTC, Tobias Müller wrote:
And if you don't give that guarantee, well then it may just
work. Or not.
Or just stop working at some point in the future.
It would be nice to have an operator that forces CTFE and
inlining.
@ct( this_is_ctfe() )
@inline(
On 6/9/15 4:06 AM, Brian Schott wrote:
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
Also, you say 5 seconds as if that's a short amount of time.
If it takes an automatic scanner 5 seconds, it means the amount
of coverage it needs to perform is huge.
If anybody was wondering
Kagamin s...@here.lot wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe guarantee at all. It
just works.
In other words you have no guarantee.
If you want the guarantee you
On Tuesday, 9 June 2015 at 20:01:24 UTC, Walter Bright wrote:
On 6/9/2015 4:25 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
When constexpr is part of the prototype you know that it isn't
supposed to do
substantial work.
That doesn't follow.
What
On 6/9/2015 4:25 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
When constexpr is part of the prototype you know that it isn't supposed to do
substantial work.
That doesn't follow.
Without it, you risk the compiler spending a lot of time computing
On 6/9/2015 2:58 AM, Jacob Carlborg wrote:
Even though the compiler makes sure there's no ambiguity it might not always be
so easy to find the definition.
I usually try to select identifiers that are easy to grep. So unless one has a
penchant for naming functions f(), in practice it isn't a
On 09/06/15 22:39, Walter Bright wrote:
I usually try to select identifiers that are easy to grep. So unless one
has a penchant for naming functions f(), in practice it isn't a
significant issue.
The difference between theory and practice is that, in theory, there is
no difference between
On 6/9/2015 4:47 AM, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe guarantee at all. It just
works.
Also, only the particular path the CTFE interpreter takes
On Tuesday, 9 June 2015 at 21:40:29 UTC, Walter Bright wrote:
You've invented your own definition of constexpr; you would as
productively tagged your C++ functions with /*simple*/.
Kind of yes, but since C++ requires it I actually use it too.
But in D, you can invent your own attribute
On 06/09/2015 06:27 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 15:49:07 UTC, Timon Gehr wrote:
On 06/09/2015 02:28 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June
On 06/09/2015 08:33 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 9 June 2015 at 18:20:43 UTC, Tobias Müller wrote:
And if you don't give that guarantee, well then it may just work. Or not.
Or just stop working at some point in the future.
It
On 6/9/2015 1:25 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 9 June 2015 at 20:01:24 UTC, Walter Bright wrote:
On 6/9/2015 4:25 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
When constexpr is part of the
On 6/9/2015 1:06 PM, Shachar Shemesh wrote:
In practice, when your code gets big enough in a certain field, similar names
are pretty much unavoidable. Admittedly, this is mostly around variable names. I
lost count over the number of variables called diskIdx I have. While not
exactly duplicate
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe guarantee
at all. It just works.
Huh? As I understood you, you asked for a
On Tuesday, 9 June 2015 at 12:28:04 UTC, Marc Schütz wrote:
Huh? As I understood you, you asked for a guarantee that a
function is CTFEable, in order to not break other people's
code.
I mean http://forum.dlang.org/post/ml54jr$107j$1...@digitalmars.com
On 9 June 2015 at 16:54, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to unify the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing
functions of either kind
On 6/9/2015 4:02 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 9 June 2015 at 21:40:29 UTC, Walter Bright wrote:
You've invented your own definition of constexpr; you would as productively
tagged your C++ functions with /*simple*/.
Kind of
On 06/09/2015 04:58 AM, Shachar Shemesh wrote:
I would have a considerably less problem with UFCS had it been limited
only to explicit declaration.
That's how it works in C#. That was actually my first introduction with
extension methods, and then when UFCS was added to D, I used to be
On 10/06/15 00:29, Walter Bright wrote:
First off, D does not allow shadowing local variable declarations.
Secondly, if you've got a lot of global variables, you've got a program
design problem anyway. And lastly, naming everything diskIdx is a
problem of your own creation.
The first one is
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote:
stuck with grep for C
Eww. Have you tried cscope?
-Wyatt
On Monday, 8 June 2015 at 18:57:17 UTC, ponce wrote:
I can't imagine the weird look-up rules that will be made for a
translation unit both using modules and traditional headers. At
the end of the day, another set of rules for C++ers to
remembers.
I wonder when they will realize that a clean
On 08-Jun-2015 22:24, Walter Bright wrote:
On 6/8/2015 11:17 AM, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical Specification,
and won't be
ready on time for inclusion into ANSI C++ 17.
On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote:
On Monday, 8 June 2015 at 18:57:17 UTC, ponce wrote:
I can't imagine the weird look-up rules that will be made for
a translation unit both using modules and traditional headers.
At the end of the day, another set of rules for C++ers to
Apparently modules have been pushed into a Technical
Specification, and won't be ready on time for inclusion into ANSI
C++ 17.
https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
So, here is another feature that D wins over C++.
--
Paulo
On Mon, 08 Jun 2015 18:24:13 +
Dennis Ritchie via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't be ready on time for inclusion into
ANSI C++
On 6/8/2015 11:17 AM, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical Specification, and won't be
ready on time for inclusion into ANSI C++ 17.
https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
So, here is another feature
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't be ready on time for inclusion into
ANSI C++ 17.
https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
So, here
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't be ready on time for inclusion into
ANSI C++ 17.
https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
So, here
On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote:
On 6/8/2015 11:17 AM, Paulo Pinto wrote:
Apparently modules have been pushed into a Technical
Specification, and won't be
ready on time for inclusion into ANSI C++ 17.
On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote:
On Monday, 8 June 2015 at 18:57:17 UTC, ponce wrote:
I can't imagine the weird look-up rules that will be made for
a translation unit both using modules and traditional headers.
At the end of the day, another set of rules for C++ers to
On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote:
I see a problem that having those features in C++ will reduce
the desire from companies to adopt D.
There is certainly some truth to that, but I think that it's
pretty clear that in most cases, they can't do as good a job of
it as D,
On 6/8/15 1:25 PM, ponce wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time code
looking like runtime code. But I never had the pleasure to use it.
Yeah, it's sadly quite björked. Scott Meyers and I looked at the
On Monday, 8 June 2015 at 19:57:34 UTC, Dmitry Olshansky wrote:
And they seem to almost have CTFE(!)
From wiki on C++14:
C++11 introduced the concept of a constexpr-declared function;
a function which could be executed at compile time. Their
return values could be consumed by operations that
On 6/8/15 12:48 PM, Paulo Pinto wrote:
I see a problem that having those features in C++ will reduce the desire
from companies to adopt D.
At very least they should acknowledge all of you guys for the ideas.
As I said at DConf, D is the N word of C++. It's actually comical to
watch the
On 06/08/2015 03:55 PM, Jonathan M Davis wrote:
On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote:
I wonder when they will realize that a clean break is necessary. 36
years is far too long for a language to keep building on top of the
past. Intel has been hurt by this with x86 recently,
On 6/8/15 2:43 PM, Tobias Müller wrote:
ponce cont...@gam3sfrommars.fr wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time code looking
like runtime code. But I never had the pleasure to use it.
constexpr functions
ponce cont...@gam3sfrommars.fr wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time code looking
like runtime code. But I never had the pleasure to use it.
constexpr functions are just as well runtime functions. They
On Monday, 8 June 2015 at 19:47:07 UTC, Paulo Pinto wrote:
That is why Microsoft is going forward with WinRT.
It is nice that they're updating the APIs, but I heard that a lot
of it is just wrappers around old ones. The bigger issue is that
Windows 7 and 8 (haven't tried the preview builds
1 - 100 of 101 matches
Mail list logo
