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.
Probably a tooling issue, for me it works instantly for C#.
 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.
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 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