On Wednesday, 14 November 2012 at 19:12:59 UTC, Timon Gehr wrote:
On 11/14/2012 06:43 PM, foobar wrote:
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
I'm wondering why overloading has been implemented to only
match on
the argument list rather than the full signature which
I've been wondering for a couple of years about why overloading
stops at the argument sig in almost all languages, but so far I
have not seen a good reason why this must be so.
From what I've read so far, the reason why full overloading is
not being done, is because it is not being done.
On Thursday, 15 November 2012 at 17:18:04 UTC, Rob T wrote:
I've been wondering for a couple of years about why overloading
stops at the argument sig ...
[SNIP]
--rt
I'd say because overall, you gain *very* little out of it, and it
costs you much more complex compiler rules.
Most of all
monarch_dodra:
I mean, are there even any real use-cases for overload on
return type?
In Haskell many functions are overloaded on the return type
(like the fromString function), and it's nice. But Haskell is
able to do it because it has a global type inferencer.
Bye,
bearophile
Am 14.11.2012 20:07, schrieb Timon Gehr:
On 11/14/2012 06:30 PM, Rob T wrote:
On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
I'm not requesting this to be a feature of D, I'm only asking why it
is not
being done.
Because types are resolved bottom-up, and if the return
On Thursday, 15 November 2012 at 17:33:24 UTC, monarch_dodra
wrote:
I'd say because overall, you gain *very* little out of it, and
it costs you much more complex compiler rules.
But how little, and for how much extra cost? Overloading already
has a cost to it, and it's really difficult for
On 11/15/2012 07:09 PM, Sönke Ludwig wrote:
Am 14.11.2012 20:07, schrieb Timon Gehr:
On 11/14/2012 06:30 PM, Rob T wrote:
On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
I'm not requesting this to be a feature of D, I'm only asking why it
is not
being done.
Because
On Thursday, November 15, 2012 17:18:43 foobar wrote:
I thought that Haskell doesn't have function overloading (which
simplifies this greatly)... Anyway, I mostly meant standard
imperative/OO languages. Sorry for the confusion.
It has pattern matching (which typically results in several of the
On Friday, 16 November 2012 at 01:02:59 UTC, Jonathan M Davis
wrote:
On Thursday, November 15, 2012 17:18:43 foobar wrote:
I thought that Haskell doesn't have function overloading (which
simplifies this greatly)... Anyway, I mostly meant standard
imperative/OO languages. Sorry for the
Am 15.11.2012 22:05, schrieb Timon Gehr:
On 11/15/2012 07:09 PM, Sönke Ludwig wrote:
Am 14.11.2012 20:07, schrieb Timon Gehr:
On 11/14/2012 06:30 PM, Rob T wrote:
On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
I'm not requesting this to be a feature of D, I'm only asking
On Wednesday, 14 November 2012 at 07:26:44 UTC, Tove wrote:
it would be a very useful feature to allow overload on void and
1 other type... as sometimes the return is very expensive to
calculate... I have seen this trick used by compiler build-in
functions.
struct A
{
int i;
string s;
On Wednesday, 14 November 2012 at 08:25:30 UTC, Rob T wrote:
Was the single conversion limitation specified by design, or do
we have room to expand it to allow for multiple conversions?
http://d.puremagic.com/issues/show_bug.cgi?id=6083
I guess it will be expanded to allow multiple
Actually the (x) = y style delegates compute their return type exactly by
looking at the left-hand side. This exact thing is already being done. If
the ambiguity cannot be resolved, the return type is explicitly set OR the
result is casted to a type.
Having normal functions behave this way doesn't
On Wednesday, November 14, 2012 13:05:41 Gor Gyolchanyan wrote:
Actually the (x) = y style delegates compute their return type exactly by
looking at the left-hand side. This exact thing is already being done. If
the ambiguity cannot be resolved, the return type is explicitly set OR the
result
On 11/13/2012 1:34 PM, Rob T wrote:
I'm wondering why overloading has been implemented to only match on the argument
list rather than the full signature which includes the return type? I know I
would use it if it was available.
I'm not requesting this to be a feature of D, I'm only asking why
On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright
wrote:
I'm not requesting this to be a feature of D, I'm only asking
why it is not
being done.
Because types are resolved bottom-up, and if the return type
were part of the overloading, there would be no sensible rule
to
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
I'm wondering why overloading has been implemented to only
match on the argument list rather than the full signature which
includes the return type? I know I would use it if it was
available.
I'm not requesting this to be a feature
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
In C++ there are conversion operators, which are not exactly
the same as function overloading, but the correct function is
selected based on the type on the left hand side.
Example
class A
{
operator bool(){ return _b; }
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
In C++ there are conversion operators, which are not exactly
the same as function overloading, but the correct function is
selected based on the type on the left hand side.
Example
class A
{
operator bool(){ return _b; }
On 11/14/2012 06:30 PM, Rob T wrote:
On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
I'm not requesting this to be a feature of D, I'm only asking why it
is not
being done.
Because types are resolved bottom-up, and if the return type were part
of the overloading, there
On 11/14/2012 06:43 PM, foobar wrote:
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
I'm wondering why overloading has been implemented to only match on
the argument list rather than the full signature which includes the
return type? I know I would use it if it was available.
I'm
I'm wondering why overloading has been implemented to only match
on the argument list rather than the full signature which
includes the return type? I know I would use it if it was
available.
I'm not requesting this to be a feature of D, I'm only asking why
it is not being done.
--rt
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
I'm wondering why overloading has been implemented to only
match on the argument list rather than the full signature which
includes the return type? I know I would use it if it was
available.
If it worked on return type, how would it
On Tuesday, 13 November 2012 at 21:37:38 UTC, Peter Alexander
wrote:
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
I'm wondering why overloading has been implemented to only
match on the argument list rather than the full signature
which includes the return type? I know I would
On Tuesday, November 13, 2012 22:37:37 Peter Alexander wrote:
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
I'm wondering why overloading has been implemented to only
match on the argument list rather than the full signature which
includes the return type? I know I would use it
On Wednesday, 14 November 2012 at 02:01:56 UTC, Jonathan M Davis
wrote:
It would also screw up covariant return types if overloading
too the return
type into account. I believe that the _big_ reason though is
simply because
the type of the expression is determined by the return type,
not what
On 2012-11-14 07:52, Rob T wrote:
Is there anything like C++ conversion operators in D? I have used
conversion ops in C++ and may want to use a similar feature in D if
available.
There's alias this, but you can currently only do one conversion for a
given type.
--
/Jacob Carlborg
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
On Wednesday, 14 November 2012 at 02:01:56 UTC, Jonathan M
Davis wrote:
Is there anything like C++ conversion operators in D? I have
used conversion ops in C++ and may want to use a similar
feature in D if available.
--rt
it would
28 matches
Mail list logo
