www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Modules dropped out of C++17

reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jun 08 2015
next sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
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 is another feature that D wins over C++.

 --
 Paulo


Great news for fans of D, of course :)
Jun 08 2015
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Jun 2015 18:24:13 +0000
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++ 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


 
 Great news for fans of D, of course :)


Yep, until C++ will have modules support I will stay on D ;)
Jun 08 2015
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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 is another feature that D wins over C++.

 --
 Paulo


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.
Jun 08 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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 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, 
probably Microsoft with Windows too.
Jun 08 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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 
 remembers.


 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, probably Microsoft with Windows too.


That is why Microsoft is going forward with WinRT.
Jun 08 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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 for 10) both 
feel noticeably slower to me on the _same_ hardware than FreeBSD 
or linux.  I bet backwards compatibility has a part to play in 
that.

On Monday, 8 June 2015 at 19:55:34 UTC, 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, probably Microsoft with Windows too.


 There's no point in C++ having a clean break. If you're doing 
 that, you might as well just create a new language like D. If 
 C++ had a clean break, it wouldn't be C++ anymore, and many of 
 the folks who continue to use C++ are the ones who want it to 
 be backwards compatible. Arguably, if anything, languages like 
 D and Rust _are_ the clean break.


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 
all those devs over the years, but make breaking changes that 
allow the language to get much better and cleaner.  One of the 
main changes I'd pursue is getting rid of the preprocessor, 
though I don't know how feasible that is.

You may be right that the C++ crowd is now mostly legacy-oriented 
and wouldn't want such a change, while those who want something 
different are already moving on to D and Rust, but that doesn't 
speak too well for the future viability of C++. ;)
Jun 08 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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 all those devs over the years, but make
 breaking changes that allow the language to get much better and cleaner.  One
of
 the main changes I'd pursue is getting rid of the preprocessor, though I don't
 know how feasible that is.


It's feasible.

For example, they could introduce version and static if to replace conditional 
compilation.
Jun 08 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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 
 remembers.


 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, probably Microsoft with Windows too.


There's no point in C++ having a clean break. If you're doing 
that, you might as well just create a new language like D. If C++ 
had a clean break, it wouldn't be C++ anymore, and many of the 
folks who continue to use C++ are the ones who want it to be 
backwards compatible. Arguably, if anything, languages like D and 
Rust _are_ the clean break.

- Jonathan M Davis
Jun 08 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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, probably
 Microsoft with Windows too.


 There's no point in C++ having a clean break. If you're doing that, you
 might as well just create a new language like D. If C++ had a clean
 break, it wouldn't be C++ anymore, and many of the folks who continue to
 use C++ are the ones who want it to be backwards compatible. Arguably,
 if anything, languages like D and Rust _are_ the clean break.


Exactly the point. A clean break is both needed and available, however, 
gigantic resources are still being poured into patching up C++ anyway, 
instead of putting those resources into finally jumping ship. C++ is 
programmer heroin.
Jun 08 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 that D wins over C++.


Looks like C++ is adopting ever more D features:


"proposed a syntax for declaring preconditions, postconditions, and invariants 
for a function in its interface (i.e. in its declaration), primarily for the 
purpose of static analysis and enabling compiler optimizations."

"Bjarne presented the latest version of his proposal for automatically 
generating comparison operators for class types."

"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."

"A restricted form of static_if;"

"Extending static_assert to allow taking for the error message not just a
string 
literal, but any constant expression that can be converted to a string literal."

"noexcept(auto), which basically means “deduce the noexcept-ness of this 
function from the noexcept-ness of the functions it calls." (This is
essentially 
doing "nothrow" attribute inference.)

"Eric Niebler came to that meeting with a detailed and well fleshed-out design 
for ranges in the standard library."
Jun 08 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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-standards-meeting-in-lenexa-may-2015/


 So, here is another feature that D wins over C++.


 Looks like C++ is adopting ever more D features:


 "proposed a syntax for declaring preconditions, postconditions, 
 and invariants for a function in its interface (i.e. in its 
 declaration), primarily for the purpose of static analysis and 
 enabling compiler optimizations."

 "Bjarne presented the latest version of his proposal for 
 automatically generating comparison operators for class types."

 "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."

 "A restricted form of static_if;"

 "Extending static_assert to allow taking for the error message 
 not just a string literal, but any constant expression that can 
 be converted to a string literal."

 "noexcept(auto), which basically means “deduce the 
 noexcept-ness of this function from the noexcept-ness of the 
 functions it calls." (This is essentially doing "nothrow" 
 attribute inference.)

 "Eric Niebler came to that meeting with a detailed and well 
 fleshed-out design for ranges in the standard library."


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.
Jun 08 2015
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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, simply because they have too much baggage in the 
language. And as long as we continue to improve D, we'll stay 
ahead of them anyway.


 At very least they should acknowledge all of you guys for the 
 ideas.


Perhaps, but we're all borrowing from each other all the time, 
and it's frequently the case that acknowledgement isn't given - 
and when it is, at least some of the time, it's given to someone 
who copied the idea from someone else. Sure, it might be nice if 
the C++ folks acknowledged that more of what they're adding to 
C++ came from D, but really, we just want them to start using D. 
:)

And Andrei actually pointed out in a panel at dconf that he 
doesn't care about getting credit. So, I don't think that Walter 
or Andrei are all that worried about it.

Still, I thought that it was pretty sad when Walter pointed out 
to me that he'd recently heard/read someone state that CTFE was 
inspired by C++'s constexpr. I have to laugh at it though.

What matters at the end of the day is if we can make D a 
successful language that we want to use and not whether other 
folks give us credit when they borrow our ideas (much as it would 
be nice to get credit from time to time), especially when you 
consider how many ideas we borrowed from elsewhere without really 
worrying about giving credit.

- Jonathan M Davis
Jun 08 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 lengths at which some folks in the community go to not mention D.

Anyhow, C++ playing catch up means we're doing the right things and they 
shoot where we were a while ago. I hope the next thing for us is Design 
by Introspection, which is going to knock the socks off everyone.


Andrei
Jun 08 2015
parent "ponce" <contact gam3sfrommars.fr> writes:
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 DConf, D is the N word of C++. It's actually 
 comical to watch the lengths at which some folks in the 
 community go to not mention D.

 Anyhow, C++ playing catch up means we're doing the right things 
 and they shoot where we were a while ago. I hope the next thing 
 for us is Design by Introspection, which is going to knock the 
 socks off everyone.


 Andrei


This compile-time duck-typing thing does ring like something from 
the future, and it is interestingly different from C++'s concepts 
/ Rust traits / Haskell typeclasses. It's gonna be useful 
whenever one wants to write a good abstraction for X (which is 
super hard).
Jun 08 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
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://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++.


 Looks like C++ is adopting ever more D features:


 "proposed a syntax for declaring preconditions, 
 postconditions, and invariants for a function in its interface 
 (i.e. in its declaration), primarily for the purpose of static 
 analysis and enabling compiler optimizations."

 "Bjarne presented the latest version of his proposal for 
 automatically generating comparison operators for class types."

 "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."

 "A restricted form of static_if;"

 "Extending static_assert to allow taking for the error message 
 not just a string literal, but any constant expression that 
 can be converted to a string literal."

 "noexcept(auto), which basically means “deduce the 
 noexcept-ness of this function from the noexcept-ness of the 
 functions it calls." (This is essentially doing "nothrow" 
 attribute inference.)

 "Eric Niebler came to that meeting with a detailed and well 
 fleshed-out design for ranges in the standard library."




This is really funny. After years of ignoring or bashing and 
ridiculing D. Those who work with D know who useful these 
features are. They must have worked with it too ;)


 I see a problem that having those features in C++ will reduce 
 the desire from companies to adopt D.


Yes and no. In D these features have been carefully crafted to be 
part and parcel of the language (there are still some rough 
edges, but well). In C++ it's gonna be the usual "glue it on top 
of what we have and make complicated rules in order not interfere 
with legacy code". In short, it's gonna be a nightmare to use and 
people will stick to what they know, I think.


 At very least they should acknowledge all of you guys for the 
 ideas.


They would never do that.
Jun 09 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
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 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++.


 Looks like C++ is adopting ever more D features:


 "proposed a syntax for declaring preconditions, 
 postconditions, and invariants for a function in its 
 interface (i.e. in its declaration), primarily for the 
 purpose of static analysis and enabling compiler 
 optimizations."

 "Bjarne presented the latest version of his proposal for 
 automatically generating comparison operators for class 
 types."

 "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."

 "A restricted form of static_if;"

 "Extending static_assert to allow taking for the error 
 message not just a string literal, but any constant 
 expression that can be converted to a string literal."

 "noexcept(auto), which basically means “deduce the 
 noexcept-ness of this function from the noexcept-ness of the 
 functions it calls." (This is essentially doing "nothrow" 
 attribute inference.)

 "Eric Niebler came to that meeting with a detailed and well 
 fleshed-out design for ranges in the standard library."




 This is really funny. After years of ignoring or bashing and 
 ridiculing D. Those who work with D know who useful these 
 features are. They must have worked with it too ;)


 I see a problem that having those features in C++ will reduce 
 the desire from companies to adopt D.


 Yes and no. In D these features have been carefully crafted to 
 be part and parcel of the language (there are still some rough 
 edges, but well). In C++ it's gonna be the usual "glue it on 
 top of what we have and make complicated rules in order not 
 interfere with legacy code". In short, it's gonna be a 
 nightmare to use and people will stick to what they know, I 
 think.



+1
the range library proposal is *ugly,* and the author did the best 
he could honestly.

on the topic of D advancing ahead of C++, I think language 
built-in tuples and pattern matching would be a good start : )
Jun 09 2015
parent "weaselcat" <weaselcat gmail.com> writes:
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 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++.


 Looks like C++ is adopting ever more D features:


 "proposed a syntax for declaring preconditions, 
 postconditions, and invariants for a function in its 
 interface (i.e. in its declaration), primarily for the 
 purpose of static analysis and enabling compiler 
 optimizations."

 "Bjarne presented the latest version of his proposal for 
 automatically generating comparison operators for class 
 types."

 "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."

 "A restricted form of static_if;"

 "Extending static_assert to allow taking for the error 
 message not just a string literal, but any constant 
 expression that can be converted to a string literal."

 "noexcept(auto), which basically means “deduce the 
 noexcept-ness of this function from the noexcept-ness of the 
 functions it calls." (This is essentially doing "nothrow" 
 attribute inference.)

 "Eric Niebler came to that meeting with a detailed and well 
 fleshed-out design for ranges in the standard library."




 This is really funny. After years of ignoring or bashing and 
 ridiculing D. Those who work with D know who useful these 
 features are. They must have worked with it too ;)


 I see a problem that having those features in C++ will reduce 
 the desire from companies to adopt D.


 Yes and no. In D these features have been carefully crafted to 
 be part and parcel of the language (there are still some rough 
 edges, but well). In C++ it's gonna be the usual "glue it on 
 top of what we have and make complicated rules in order not 
 interfere with legacy code". In short, it's gonna be a 
 nightmare to use and people will stick to what they know, I 
 think.



 +1
 the range library proposal is *ugly,* and the author did the 
 best he could honestly.


also, I wonder what the assembly output using the ranges proposal 
looks like. I often see my range code boiled down to a few vector 
ops by GDC and LDC, but AFAIK a lot of effort has gone into 
making ranges as efficient as possible.
Jun 09 2015
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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-lenexa-may-2015/



 So, here is another feature that D wins over C++.


 Looks like C++ is adopting ever more D features:


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 require constant expressions, such 
as an integer template argument. However, C++11 constexpr functions 
could only contain a single expression that is returned (as well as 
static_asserts and a small number of other declarations).

C++14 relaxes these restrictions. Constexpr-declared functions may now 
contain the following:[5]

     Any declarations except:
         static or thread_local variables.
         Variable declarations without initializers.
     The conditional branching statements if and switch.
     All looping statements, including range-based for.
     Expressions which change the value of an object if the lifetime of 
that object began within the constant expression function. This includes 
calls to any non-const constexpr-declared non-static member functions.

goto statements are forbidden in C++14 relaxed constexpr-declared functions.

-- 
Dmitry Olshansky
Jun 08 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
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 require 
 constant expressions, such as an integer template argument. 
 However, C++11 constexpr functions could only contain a single 
 expression that is returned (as well as static_asserts and a 
 small number of other declarations).

 C++14 relaxes these restrictions. Constexpr-declared functions 
 may now contain the following:[5]

     Any declarations except:
         static or thread_local variables.
         Variable declarations without initializers.
     The conditional branching statements if and switch.
     All looping statements, including range-based for.
     Expressions which change the value of an object if the 
 lifetime of that object began within the constant expression 
 function. This includes calls to any non-const 
 constexpr-declared non-static member functions.

 goto statements are forbidden in C++14 relaxed 
 constexpr-declared functions.


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.
Jun 08 2015
next sibling parent reply =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
"ponce" <contact 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 are only
annotated that they are usable in a constant expression.
I don't think it's fair to call that broken regarding all the attributes
that D functions can take...

Tobi
Jun 08 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/8/15 2:43 PM, Tobias Müller wrote:

 "ponce" <contact 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 are only
 annotated that they are usable in a constant expression.
 I don't think it's fair to call that broken regarding all the attributes
 that D functions can take...


"A job well done" doesn't quite spring to mind, either.

FWIW, a reference to D came about on 
http://www.reddit.com/r/programming/comments/392jxf/modules_wont_make_it_in_c17/.


Andrei
Jun 08 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 feature 
and the logical conclusion for a guideline was "Speculatively mark 
everything in sight as constexpr". That doesn't quite scale. -- Andrei
Jun 08 2015
parent reply "Kagamin" <spam here.lot> writes:
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.


 Yeah, it's sadly quite björked. Scott Meyers and I looked at 
 the feature and the logical conclusion for a guideline was 
 "Speculatively mark everything in sight as constexpr". That 
 doesn't quite scale. -- Andrei


Same as with  safe  nogc  nothrow  pure. If you don't have 
ctfeability expressed in function's contract, you have no idea 
how you can modify the function's implementation so that to not 
break other people's code. Sorry for making c++ look cute again :)
Jun 09 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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 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 feature and the logical conclusion for a guideline was 
 "Speculatively mark everything in sight as constexpr". That 
 doesn't quite scale. -- Andrei


 Same as with  safe  nogc  nothrow  pure. If you don't have 
 ctfeability expressed in function's contract, you have no idea 
 how you can modify the function's implementation so that to not 
 break other people's code. Sorry for making c++ look cute again 
 :)


simple solution:
just make everything a template, and alias empty-templated 
functions ;)

also, AFAIK in 2.068 auto return functions are getting attribute 
inference.
Jun 09 2015
parent "Kagamin" <spam here.lot> writes:
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.
Jun 09 2015
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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 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 feature and the logical conclusion for a guideline was 
 "Speculatively mark everything in sight as constexpr". That 
 doesn't quite scale. -- Andrei


 Same as with  safe  nogc  nothrow  pure. If you don't have 
 ctfeability expressed in function's contract, you have no idea 
 how you can modify the function's implementation so that to not 
 break other people's code. Sorry for making c++ look cute again 
 :)


static assert() is your friend in this case. See also the related 
problem of guaranteeing that a template is nothrow/ nogc/whatever 
by itself (i.e. doesn't do anything that violates them), even 
though it cannot be marked as such because that would preclude 
instantiating it with certain types that aren't nothrow/ nogc.
Jun 09 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 compiler spending a lot of time 
computing constants/tables that should be done at runtime to save 
compile time and object code size. And since C++ programmers 
expect that level of control, it would have ended up as a pragma 
if it was not part of the language?

Not saying one way is obviously better than the other. I think 
LLVM (and all the open source starting points available) paves 
the way for performant high level languages by reducing the cost 
of building a backend. Maybe in some unexpected direction that 
fits next-gen hardware better than C-descendants.
Jun 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/9/2015 4:25 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang 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
 constants/tables that should be done at runtime to save compile time and object
 code size. And since C++ programmers expect that level of control, it would
have
 ended up as a pragma if it was not part of the language?


This is just made up problems.
Jun 09 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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+dlang 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 doesn't follow? All my constexpr functions are simple. I 
absolutely don't want to solve N-Queens problems at CT.


 Without it, you risk the compiler spending a lot of time 
 computing
 constants/tables that should be done at runtime to save 
 compile time and object
 code size. And since C++ programmers expect that level of 
 control, it would have
 ended up as a pragma if it was not part of the language?


 This is just made up problems.


Nah, sometimes I want my big lookup tables to be evaluated at 
runtime so I don't get bloated binaries. But neither C++ or D 
cuts it. Because sometimes I want the code that uses constant 
indexing to look it up in the LUT, but actually generate the LUT 
at runtime.

Can D check that a parameter is a CT value so that one can 
overload on it? That would work.
Jun 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/9/2015 1:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang 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+dlang 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 doesn't follow? All my constexpr functions are simple.


You've invented your own definition of constexpr; you would as productively 
tagged your C++ functions with /*simple*/.

But in D, you can invent your own attribute  simple, and then tag functions
with 
that.
Jun 09 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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, and then 
 tag functions with that.


I could, but D would not check it?
Jun 09 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/9/2015 4:02 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang 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 yes, but since C++ requires it I actually use it too.


 But in D, you can invent your own attribute  simple, and then tag functions
 with that.


 I could, but D would not check it?


I'm bemused by the argument that D is deficient because it doesn't implement a 
non-existent feature of C++.

You're smart, capable, and well educated in programming. You have great 
potential for contributing, which is why I answer some of these posts. I'm 
hoping to entice you to contribute in the substantial way that I know you can.
Jun 09 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 moving more 
in a high level direction than C++. Which is neither good or bad, 
just different. "constexpr" has advantages and disadvantages.

But C++ constexpr was originally restricted to expression-like 
functions. Loops were added later (making it easier to init 
arrays)  AFAIK.

My primary use case for constexpr in C++ is:

1. Initializing global constant arrays. These functions I label 
"ct_make_lut_sin(size)" etc and only use them for that purpose.

2. Signifiying that a standard class member-function is returning 
a constant value in a particular version of the class where you 
expect a varying value, e.g. "size()".

I only add constexpr when I have to and only use constexpr 
functions that are O(N) and only where beneficial. It's more like 
"Do I _have_ to make this constexpr?", not "Oh yes, I can make 
this constexpr!".

However, D's primary advantage over C++ is that D is easier to 
get into. No sane person would want to learn C++ from scratch (if 
they have other options). C++XX is more for people that already 
know it or have to learn it (for work).

D's position will benefit from becoming simpler and more 
streamlined, not more complex, so "constexpr" is not the right 
thing for D, IMO. (Rust and C++ have complexity as a 
barrier-to-entry)


 some of these posts. I'm hoping to entice you to contribute in 
 the substantial way that I know you can.


I think prodding people to view things differently is 
substantial, besides it helps me figure out what I want from a 
language ;-). But I suppose you mean code, I am thinking about 
doing comparative synthetic benchmarks between 
"idiomatic/readable" C++, Rust and D vs "not-so-readable hardware 
oriented C".

I think you will find that more people will chime in when the 
compiler has completed the transition to D and the codebase has 
been refactored. It doesn't make much sense to get into the C++ 
codebase at this point where you are transitioning.
Jun 09 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-06-10 01:02, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 I could, but D would not check it?


It could most likely be implemented with AST macros.

-- 
/Jacob Carlborg
Jun 10 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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.
Jun 09 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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 guarantee that a 
function is CTFEable, in order to "not break other people's 
code". static assert() gives you that:

     static assert(__traits(compiles, { enum dummy = myFunction(); 
}));
Jun 09 2015
next sibling parent "Kagamin" <spam here.lot> writes:
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
Jun 09 2015
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/09/2015 02:28 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
<schuetzm 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 guarantee at
 all. It just works.


 Huh? As I understood you, you asked for a guarantee that a function is
 CTFEable, in order to "not break other people's code". static assert()
 gives you that:

      static assert(__traits(compiles, { enum dummy = myFunction(); }));


What if you don't support it, but it works by accident?
Jun 09 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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=?= 
 <schuetzm 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 
 guarantee at
 all. It just works.


 Huh? As I understood you, you asked for a guarantee that a 
 function is
 CTFEable, in order to "not break other people's code". static 
 assert()
 gives you that:

     static assert(__traits(compiles, { enum dummy = 
 myFunction(); }));


 What if you don't support it, but it works by accident?


If you don't want to support it, why _would_ you put the static 
assert() in? Or do you mean something else?
Jun 09 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/09/2015 06:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
<schuetzm 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=?=
 <schuetzm 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 guarantee at
 all. It just works.


 Huh? As I understood you, you asked for a guarantee that a function is
 CTFEable, in order to "not break other people's code". static assert()
 gives you that:

     static assert(__traits(compiles, { enum dummy = myFunction(); }));


 What if you don't support it, but it works by accident?


 If you don't want to support it, why _would_ you put the static assert()
 in? Or do you mean something else?


Basically, the scenario that *lack* of constexpr is able to successfully 
avoid by default is that you write a function that just so happens to 
work in CTFE but doesn't in the next release, and your dependencies 
break (in D you'd need to add an explicit if(__ctfe) assert(0), or 
similar.) I.e. lack of constexpr is a kind of enforced documentation. 
Anyway, I don't think this is worth the additional trouble.
Jun 09 2015
prev sibling next sibling parent reply =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
"Kagamin" <spam 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 have to ensure it via static assert or
unittest and you have to document it. The constexpr attribute covers both
at once.
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.
Jun 09 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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_is_inlined() )
Jun 09 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/09/2015 08:33 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang 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 would be nice to have an operator that forces CTFE and inlining.

  ct( this_is_ctfe() )

  inline( this_is_inlined() )


enum ct(alias a)=a;
Jun 09 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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_sin[x]"
Jun 10 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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 the function 
needs to be CTFE'able, not all the paths. This makes it starkly different from 
constexpr.
Jun 09 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 never had the pleasure to use it.


 Yeah, it's sadly quite björked. Scott Meyers and I looked at the
 feature and the logical conclusion for a guideline was "Speculatively
 mark everything in sight as constexpr". That doesn't quite scale. --
 Andrei


 Same as with  safe  nogc  nothrow  pure.


No, these are attributes that change the function's type; constexpr does 
not. (Plus, in D the attributes may be applied in bulk with ":" or "{}").


 If you don't have ctfeability
 expressed in function's contract, you have no idea how you can modify
 the function's implementation so that to not break other people's code.
 Sorry for making c++ look cute again :)


I guess you could do a lot worse than using a unittest to make sure a 
function is CTFEable.


Andrei
Jun 09 2015
next sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
Andrei Alexandrescu <SeeWebsiteForEmail 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?
Jun 09 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
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 contract, you have no idea how you can 
 modify
 the function's implementation so that to not break other 
 people's code.
 Sorry for making c++ look cute again :)


 I guess you could do a lot worse than using a unittest to make 
 sure a function is CTFEable.


Isn't it "Speculatively mark everything in sight as ctfe"?
Jun 10 2015
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
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 most confusing aspects of D. It makes it close to 
impossible to locate the definition for a function used.

Shachar
Jun 08 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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 either 
 kind."


 Dear god, I hope this doesn't pass.

 It is one of the most confusing aspects of D. It makes it close 
 to impossible to locate the definition for a function used.

 Shachar


It is no different than extension methods in .NET, Ceylon, 
Kotlin, multi-methods in CLOS or implicits in Scala.


I just mouse hover, press F12/Ctrl+Right Mouse and in less than 
5s is the method visible.
Jun 09 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
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 clearing up anything? It completely ignores the 
reasons why so and so was claimed to be bad.


 I just mouse hover, press F12/Ctrl+Right Mouse and in less than 5s is
 the method visible.


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. This means 
that for any action that does not involve the scanner (e.g. writing new 
code, implementing a new function, deciding which function to call), you 
need to hold in your head the amount of state it takes your scanner 5 
seconds to collect.

Which leads me back to my original claim: this feature promotes bugs.

Shachar
Jun 09 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
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 
the answer. I can't find a way to make it fast, useful, or 
compact in terms of memory use.
Jun 09 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 anybody was wondering why DCD doesn't support UFCS, this is 
 the answer. I can't find a way to make it fast, useful, or 
 compact in terms of memory use.


Resolving identifier in D is extremely complex. For instance:
https://github.com/deadalnix/SDC/blob/master/libd/src/d/semantic/identifier.d
Jun 09 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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 why DCD doesn't support UFCS, this is the
 answer. I can't find a way to make it fast, useful, or compact in terms
 of memory use.


I can't see how a UFCS lookup is any slower than a normal function 
lookup. It's just a rewrite.

i.e.:

a.foo

1. try finding member foo on type a.
2. try finding function foo
   a. If found, find overload that will take a.

What happens as you type:

foo(a

??? how is it any different?

-Steve
Jun 09 2015
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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 
 amount
 of coverage it needs to perform is huge.


 If anybody was wondering why DCD doesn't support UFCS, this is 
 the
 answer. I can't find a way to make it fast, useful, or compact 
 in terms
 of memory use.


 I can't see how a UFCS lookup is any slower than a normal 
 function lookup. It's just a rewrite.

 i.e.:

 a.foo

 1. try finding member foo on type a.
 2. try finding function foo
   a. If found, find overload that will take a.

 What happens as you type:

 foo(a

 ??? how is it any different?

 -Steve


One problem is that any auto-complete list becomes completely 
unmanageable.
Jun 10 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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 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 the
 answer. I can't find a way to make it fast, useful, or compact in terms
 of memory use.


 I can't see how a UFCS lookup is any slower than a normal function
 lookup. It's just a rewrite.

 i.e.:

 a.foo

 1. try finding member foo on type a.
 2. try finding function foo
   a. If found, find overload that will take a.

 What happens as you type:

 foo(a

 ??? how is it any different?


 One problem is that any auto-complete list becomes completely unmanageable.


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 support that option. A UI for an ide 
could be:

1. Lookup members, add to the list a "UFCS..." button at the bottom.
2. When user clicks on that button, re-query DCD for all functions that 
take the object as the first parameter, then fill in that list.
3. If user continues to type in a UFCS method, and that doesn't match 
any members, the autocomplete should start looking for functions that 
start with that text.

It would be a shame if DCD doesn't show you functions like arr.empty.

However, does DCD support querying a function's parameters when it's a 
UFCS function? That should at least be manageable.

-Steve
Jun 11 2015
next sibling parent "krzaq" <dlangmailinglist krzaq.cc> writes:
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 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 the
 answer. I can't find a way to make it fast, useful, or 
 compact in terms
 of memory use.


 I can't see how a UFCS lookup is any slower than a normal 
 function
 lookup. It's just a rewrite.

 i.e.:

 a.foo

 1. try finding member foo on type a.
 2. try finding function foo
  a. If found, find overload that will take a.

 What happens as you type:

 foo(a

 ??? how is it any different?


 One problem is that any auto-complete list becomes completely 
 unmanageable.


 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 
 support that option. A UI for an ide could be:

 1. Lookup members, add to the list a "UFCS..." button at the 
 bottom.
 2. When user clicks on that button, re-query DCD for all 
 functions that take the object as the first parameter, then 
 fill in that list.
 3. If user continues to type in a UFCS method, and that doesn't 
 match any members, the autocomplete should start looking for 
 functions that start with that text.

 It would be a shame if DCD doesn't show you functions like 
 arr.empty.

 However, does DCD support querying a function's parameters when 
 it's a UFCS function? That should at least be manageable.

 -Steve


The funny thing is, one of selling points of C++'s version of 
UFCS is making it easier for the tools to give useful hints.

Personally, I find UFCS and ranges to be the most enticing 
features of D, allowing me to think of the flow of the data, 
instead of wondering where the hell does the ) go. Better 
templates, true immutables, mixins (though ugly), ctfe & static 
if are also appreciated.

Modules? Sure, nice to have, but they don't make the top 5 list 
for me. Why? Call it the Stockholm Syndrome, but most C++ users 
simply got used to header incurred problems and know to use PIMPL 
and avoid changing core headers. Though maybe my projects aren't 
sufficiently large.
Jun 11 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
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 support that option. A UI for an ide
 could be:

 1. Lookup members, add to the list a "UFCS..." button at the bottom.
 2. When user clicks on that button, re-query DCD for all functions that
 take the object as the first parameter, then fill in that list.
 3. If user continues to type in a UFCS method, and that doesn't match
 any members, the autocomplete should start looking for functions that
 start with that text.


The context of where the user is typing can also help to narrow the 
result, i.e.

int a = b.fo

Here it could filter out anything that doesn't return something that is 
convertible to an int. Or at least sort those to the bottom of the list.

-- 
/Jacob Carlborg
Jun 12 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
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.





 This means that for any action that does not involve the 
 scanner (e.g. writing new code, implementing a new function, 
 deciding which function to call), you need to hold in your head 
 the amount of state it takes your scanner 5 seconds to collect.


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.
Jun 09 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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-style generics, C++ and D templates are a close, but weak, 
cousin to) then adding an extension method as a first class 
method will then change the type-resolution... which affects what 
kind of features you can have that use type resolution. Is the 
extension global or local? What if two extensions differ in 
semantics, but not in name? Not a problem for nominal typing, but 
a problem for structural/duck-like typing when you scale up.
Jun 09 2015
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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 because A
 Answer: X, Y, and Z also do so and so

 How is the answer clearing up anything? It completely ignores 
 the reasons why so and so was claimed to be bad.


 I just mouse hover, press F12/Ctrl+Right Mouse and in less 
 than 5s is
 the method visible.


 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. This means that for any action that does not involve 
 the scanner (e.g. writing new code, implementing a new 
 function, deciding which function to call), you need to hold in 
 your head the amount of state it takes your scanner 5 seconds 
 to collect.

 Which leads me back to my original claim: this feature promotes 
 bugs.

 Shachar


5 seconds was just an example. Usually it is almost instantaneous.
Jun 09 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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 either 
 kind."


 Dear god, I hope this doesn't pass.

 It is one of the most confusing aspects of D. It makes it close 
 to impossible to locate the definition for a function used.


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
Jun 09 2015
next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
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 *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 something that promotes bugs. 
The technical problem of finding the definition is the least important 
aspect of the problem.

Shachar
Jun 09 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
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 something that 
 promotes bugs. The technical problem of finding the definition 
 is the least important aspect of the problem.


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.
Jun 09 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
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.


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.

In the relevant C++ proposal, at least you can be sure that there is at 
most one such function. Otherwise, the linker will complain (namespaces 
notwithstanding). In D, you can't even say that. There may be three (or 
three thousand) such functions, each in its own module, and until/unless 
you try to import two such modules, you won't even notice it.

Shachar
Jun 09 2015
parent "Kagamin" <spam here.lot> writes:
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 
symbol scoping anyway.


 In the relevant C++ proposal, at least you can be sure that 
 there is at most one such function. Otherwise, the linker will 
 complain (namespaces notwithstanding). In D, you can't even say 
 that. There may be three (or three thousand) such functions, 
 each in its own module, and until/unless you try to import two 
 such modules, you won't even notice it.


This is how all free functions worked since the beginning (even 
without UFCS). It's not a feature of UFCS.
Jun 09 2015
prev sibling next sibling parent "Joakim" <dlang joakim.fea.st> writes:
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 
problem finding the possible function definitions, but have 
trouble making out which of several overloaded functions is the 
one being invoked?

On Tuesday, 9 June 2015 at 08:09:01 UTC, Atila Neves wrote:

 Why are you using grep for C? There are solutions. I use rtags 
 and my own Emacs package cmake-ide. Works a treat.


I don't search through C headers much, just for one-off stuff 
like writing D bindings.  I've used Exuberant Ctags before with 
vim for a large C++ codebase, it worked reasonably well.
Jun 09 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 09 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jun 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 significant issue.
Jun 09 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
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 theory and practice.

But in practice, there is.

(Too ashamed to admit I'm quoting Yogi Berra here, so I won't :-).


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 per-se, there is also a 
(member) function by that name. Try to find where "diskIdx" is defined, 
and you /will/ get swamped.

Shachar
Jun 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 per-se, there is also a (member) function by that name. Try
to
 find where "diskIdx" is defined, and you /will/ get swamped.


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.

You could design a language that does not allow any duplicate names anywhere, 
and no scoping rules would be required. But there's a reason no such language 
has caught on - it does not scale and is unusable.

I take that back, early BASIC implementations did have such. You could only
have 
single letter names followed by a single digit, and all names were global and 
hence must be unique. What a relief to leave that behind.
Jun 09 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
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 called so because it names the index of the disk within 
a RAID stripe. It's probably an iterator.

How would you call the second time I use such an iterator?

You might argue that the function that extracts the disk index should be 
named something more verbose (i.e. - extractTheDiskIndex), but then you 
are just repeating Ola's criticism[1] of D as if it is a desirable thing.

People on this list hold a certain paradigm in their head when they make 
design decisions. That's fine, except if you hold on to this paradigm 
and assume anything that violates it is bad code, you are going to end 
up with Go: a language only fit for those problems that happen to fall 
within that paradigm.

People have preconceptions on how code should look like. I would humbly 
like to ask people to stop ->assuming<- that anything that violates them 
is bad code.

Shachar

1 - http://forum.dlang.org/post/uvajlhfztejvwnubszpb forum.dlang.org
Jun 09 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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 everything "diskIdx" 
 is a
 problem of your own creation.


 The first one is called so because it names the index of the 
 disk within a RAID stripe. It's probably an iterator.

 How would you call the second time I use such an iterator?

 You might argue that the function that extracts the disk index 
 should be named something more verbose (i.e. - 
 extractTheDiskIndex), but then you are just repeating Ola's 
 criticism[1] of D as if it is a desirable thing.

 People on this list hold a certain paradigm in their head when 
 they make design decisions. That's fine, except if you hold on 
 to this paradigm and assume anything that violates it is bad 
 code, you are going to end up with Go: a language only fit for 
 those problems that happen to fall within that paradigm.

 People have preconceptions on how code should look like. I 
 would humbly like to ask people to stop ->assuming<- that 
 anything that violates them is bad code.

 Shachar

 1 - 
 http://forum.dlang.org/post/uvajlhfztejvwnubszpb forum.dlang.org


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).
Jun 09 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
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 UFCS.

If the D attitude is "if your style doesn't work with D, then it is 
wrong", then D has already lost.

Shachar
Jun 09 2015
parent reply "Kagamin" <spam here.lot> writes:
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 not have).


 It is not a problem in C++. It is not a problem with no UFCS.

 If the D attitude is "if your style doesn't work with D, then 
 it is wrong", then D has already lost.


Huh? If you have type's method diskIdx and a local variable 
diskIdx, and they are confusing, what it has to do with UFCS?
Jun 10 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
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();
Jun 10 2015
parent reply "Kagamin" <spam here.lot> writes:
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;
diskIdx1 = f(diskIdx1);
return diskIdx;
Jun 10 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
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();


 auto diskIdx1 = this.diskIdx;
 diskIdx1 = f(diskIdx1);
 return diskIdx;


Was this meant to prove that you can make it confusing? I have no idea 
what you were trying to convey here. Please explain the point you're 
trying to make.

What does "diskIdx1" mean?
What does f do?
Is "this.diskIdx" a member or a function?
where did the diskIdx you returned came from?

Shachar
Jun 10 2015
parent reply "Kagamin" <spam here.lot> writes:
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 confusing, what it has to do with UFCS?


 auto diskIdx = data.diskIdx();


 auto diskIdx1 = this.diskIdx;
 diskIdx1 = f(diskIdx1);
 return diskIdx;


 Was this meant to prove that you can make it confusing?


It was your requirement that variables and methods must be 
similar.


 What does "diskIdx1" mean?


Same as in your example, a variable, which receives the disk 
index.


 What does f do?


Processes the disk index and returns another index according to 
its logic.


 Is "this.diskIdx" a member or a function?


A property, which extracts the disk index as you described the 
function.


 where did the diskIdx you returned came from?


It's defined as a member of the type.
Jun 10 2015
parent Shachar Shemesh <shachar weka.io> writes:
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 variable
 diskIdx, and
 they are confusing, what it has to do with UFCS?


 auto diskIdx = data.diskIdx();


 auto diskIdx1 = this.diskIdx;
 diskIdx1 = f(diskIdx1);
 return diskIdx;


 Was this meant to prove that you can make it confusing?


 It was your requirement that variables and methods must be similar.


I made no such requirement. I just said it sometimes makes sense.

You have not answered my most important question: what was it that you 
were trying to make?

Shachar
Jun 10 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 writing hazy code or 
programming late at night and making mistakes. So it weakens the 
type system.
Jun 09 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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
 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 most confusing aspects of D. It makes it 
 close to impossible to locate the definition for a function 
 used.


 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


what would need to be done to get dscanner fit to be part of the 
standard D tool chain?
Jun 09 2015
parent "Brian Schott" <briancschott gmail.com> writes:
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.
Jun 09 2015
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
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
 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 most confusing aspects of D. It makes it 
 close to impossible to locate the definition for a function 
 used.


 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


Why are you using grep for C? There are solutions. I use rtags 
and my own Emacs package cmake-ide. Works a treat.

Atila
Jun 09 2015
prev sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote:

 stuck with grep for C


Eww.  Have you tried cscope?

-Wyatt
Jun 09 2015
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jun 09 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 either 
 kind."


 Dear god, I hope this doesn't pass.


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 
better than a method-extension feature would have done.
Jun 09 2015
parent reply Shachar Shemesh <shachar weka.io> writes:
On 09/06/15 11:35, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang 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 does not solve "std::begin" issues better than a
 method-extension feature would have done.


Actually, that's an important point for D as well.

I would have a considerably less problem with UFCS had it been limited 
only to explicit declaration.

So:
void func( ref A a, int b ) ...

A a;
a.func(12); // Should not compile IMHO

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 (though, to be fair, not 
completely alleviated).

Shachar
Jun 09 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 
 (though, to be fair, not completely alleviated).


Yes, that mirrors my thoughts exactly. To me "a.propagate(b,c)" 
reads completely different from "propagate(a,b,c)", just like 
"a.start" and "a.start()" reads different (asking vs doing). I 
want a language to enforce that.

When reading code I don't want to wonder if 
"libraryobject.print()" is a function that is part of an external 
library or if it is application code. I want that to be clear 
when skimming over the source. No IDE can help with that without 
adding clutter.

I therefore find extension-methods are more suitable for objects 
that are self-contained (like integer and string) and less 
suitable for objects that are facades for complicated machinery.  
The module/encapsulation subsystem for language BETA allows local 
extensions by injecting them into library-defined slots in the 
AST.  That way the library author get some control over what you 
can extend.

I also don't add methods much to objects in dynamic languages 
where this is integral to the programming model, only as a quick 
hack. Subclassing is usually the better option. Which is 
reflected in Python by the adding of a new class type with 
restrictions on expanding the type.
Jun 09 2015
parent reply "Kagamin" <spam here.lot> writes:
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 
 "libraryobject.print()" is a function that is part of an 
 external library or if it is application code. I want that to 
 be clear when skimming over the source. No IDE can help with 
 that without adding clutter.


Not sure how physical layout of source code affects understanding 
of "libraryobject.print()".


 Subclassing is usually the better option.


In statically typed languages you don't control types you receive 
from 3rd party code.
Jun 09 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 templates and inlined methods).

If you have full encapsulation you know that the declaration 
holds. So "x.print()" means that the declaration for the type of 
x includes "print()". That also affects what "print()" can 
reasonably be expected to affect.


 Subclassing is usually the better option.


 In statically typed languages you don't control types you 
 receive from 3rd party code.


True, but you can always wrap code in interfacing-references. I 
use this deliberately in multi-threaded code, so that I avoid 
calling the wrong methods on the wrong thread. E.g. 
"multithreaded(someobject).clear()" and 
"singlethreaded(someobject).clear()".
Jun 09 2015
parent reply "Kagamin" <spam here.lot> writes:
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 declaration 
 holds. So "x.print()" means that the declaration for the type 
 of x includes "print()".


Well, if you have full encapsulation, then you don't have 
extension methods and consequently don't have this issue.


 True, but you can always wrap code in interfacing-references. I 
 use this deliberately in multi-threaded code, so that I avoid 
 calling the wrong methods on the wrong thread. E.g. 
 "multithreaded(someobject).clear()" and 
 "singlethreaded(someobject).clear()".


This doesn't look like full encapsulation if the type behavior is 
extended this way.
Jun 09 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 programs harder 
to read.


 This doesn't look like full encapsulation if the type behavior 
 is extended this way.


It is not an extension. It is a function returning a reference 
object that holds a pointer to the object and the new interface 
methods you want it to have. It is explicit so it does not make 
programs harder to read.
Jun 09 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.




extension methods, and then when UFCS was added to D, I used to be 
pretty vocally opposed to it being implicit. But I learned to live with 
it, and then I eventually I realized it was basically *never* causing me 
any real trouble, and now I rather like not having the cognitive load of 
"would this be better as an extension method or not?" every time I 
define a function. Plus, I don't have to deal with the issue of calling 
a func where *my* code could have been much cleaner had the func's 
author made it an extension method, but they didn't, so I'm stuck 
dealing with it or going to the bother and mess of a wrapper.

I see it as a stylistic issue, now. Let the caller use whatever works 
best for their own code.

Sure, it makes it possible for the caller the use UFCS inappropriately 
and obfuscate their code in goofy ways, but in practice this is almost 
never a real issue. And besides, pretty much *any* feature can be abused 
and obfuscate code. Ex: Nothing prevents me from naming a file-loading 
function "save" (BTW, I've actually seen that in commercial production 
code - wasted half a week figuring that one out), but being able to 
choose arbitrary identifier names is still a good thing.
Jun 09 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 to be invoked by syntax of either kind."


 Dear god, I hope this doesn't pass.

 It is one of the most confusing aspects of D. It makes it close to
 impossible to locate the definition for a function used.


Just press F12 ;)
Jun 09 2015
prev sibling parent reply "ZombineDev" <valid_email he.re> writes:
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 is another feature that D wins over C++.

 --
 Paulo


Sorry, I couldn't resist to share this:
https://www.youtube.com/watch?v=ND-TuW0KIgg
Jun 10 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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/trip-report-c-standards-meeting-in-lenexa-may-2015/

 So, here is another feature that D wins over C++.

 --
 Paulo


 Sorry, I couldn't resist to share this:
 https://www.youtube.com/watch?v=ND-TuW0KIgg


Lol, that was hilarious. :D
Jun 10 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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://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


 Sorry, I couldn't resist to share this:
 https://www.youtube.com/watch?v=ND-TuW0KIgg


 Lol, that was hilarious. :D


Saw a few of those, this is far and away the best one. I guess for a 
German speaker it would be all like, meh. -- Andrei
Jun 10 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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 :)
Jun 10 2015