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 supp
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 s
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 automat
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 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.
https://boto
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.
https://botondballo.wordpress.com/2015/06/05/
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 i
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 varia
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 confusi
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();
au
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
amou
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;
diskI
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 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 c
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 n
On 2015-06-10 01:02, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
I could, but D would not check it?
It could most likely be implemented with AST macros.
--
/Jacob Carlborg
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) : lut_s
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 m
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 UFC
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 every
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 c
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
pre
On 6/9/2015 4:02 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" 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 yes, but since C++ requires it I actu
On 06/09/2015 08:33 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" 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 would be nice to have an operator
On 06/09/2015 06:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" 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=?=
" 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üt
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 @simple
On 6/9/2015 1:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" 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?=
" wrote:
When constexpr is part of the prototype you know that it isn't supposed to do
substantial work.
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 p
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?=
" wrote:
When constexpr is part of the prototype you know that it isn't
supposed to do
substantial work.
That doesn't follow.
What doesn't follow? All my constexpr functi
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 theo
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 through
On 6/9/2015 4:25 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" 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
constants/tables that should be done at r
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 s
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( this_
"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.
In other words you have no guarantee.
If you want the guarantee you have to
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
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 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 progra
Andrei Alexandrescu 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 Tuesday, 9 June 2015 at 15:49:07 UTC, Timon Gehr wrote:
On 06/09/2015 02:28 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" 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
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 I
On 06/09/2015 02:28 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" 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 guarantee at
al
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 decla
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 tem
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote:
stuck with grep for C
Eww. Have you tried cscope?
-Wyatt
On 9 June 2015 at 16:54, Shachar Shemesh via Digitalmars-d
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 syn
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 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 gu
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 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 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 co
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 li
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 writ
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: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
s
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 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 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 ha
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 b
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
Ada-
On 09/06/15 11:35, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" 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 does not solve "std::begin" issues be
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.
https
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 bec
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.
B
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 eith
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 m
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 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
p
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 somethin
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: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 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
t
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 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
it.
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 li
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 cl
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 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 eith
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 eith
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 m
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 D
On 6/8/2015 8:52 PM, Joakim wrote:
They could do something like D when it jumped to 2.0, except with better
migration paths. With some careful planning and automated source conversion
tools nowadays, it doesn't have to be that bad. The idea is you keep the C++
knowledge that is accumulated by a
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 f
On 6/8/15 2:43 PM, Tobias Müller wrote:
"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.
constexpr functions are just as well runti
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 fe
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 lengt
"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.
constexpr functions are just as well runtime functions. They are only
annotated
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, pr
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 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 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.
https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lene
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
reme
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.
https://botondballo.wordpress.com/2015/06/05/trip-report-c-standa
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
reme
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 t
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 b
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 i
On Mon, 08 Jun 2015 18:24:13 +
Dennis Ritchie via Digitalmars-d 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.
> >
> > https://bot
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 i
100 matches
Mail list logo