On Saturday, 29 June 2013 at 03:20:27 UTC, JS wrote:
I don't disagree with you and I'm not saying auto is not
useful. IMO though, auto is almost all convenience and very
little to do with solving errors.
A very simple use case is:
auto x = 0;
...
x = complex(1, 1) + x;
which obviously is an
Steven Schveighoffer wrote:
There are very good reasons not to do this, even if possible.
Especially if the type can change.
+1
This sort of inference can only lead to problems down the line,
IMO.
On 7/1/13 7:35 PM, JS wrote:
On Tuesday, 2 July 2013 at 02:15:09 UTC, Andrei Alexandrescu wrote:
On 7/1/13 6:29 PM, JS wrote:
Would would be nice is an experimental version of D where would could
easily extend the language to try out such concepts to see if they truly
are useful and how difficu
On Tuesday, 2 July 2013 at 03:17:58 UTC, Ali Çehreli wrote:
On 07/01/2013 07:35 PM, JS wrote:
> On Tuesday, 2 July 2013 at 02:15:09 UTC, Andrei Alexandrescu
wrote:
>> auto a = 2.5; // fine, a is double
>> ...
>> a = 3;
>>
>
> No, not under what I am talking about. You can't downgrade a
type, on
On 07/01/2013 07:35 PM, JS wrote:
> On Tuesday, 2 July 2013 at 02:15:09 UTC, Andrei Alexandrescu wrote:
>> auto a = 2.5; // fine, a is double
>> ...
>> a = 3;
>>
>
> No, not under what I am talking about. You can't downgrade a type, only
> upgrade it. a = 3, a is still a float. Using the concept
On Tuesday, 2 July 2013 at 02:15:09 UTC, Andrei Alexandrescu
wrote:
On 7/1/13 6:29 PM, JS wrote:
Would would be nice is an experimental version of D where
would could
easily extend the language to try out such concepts to see if
they truly
are useful and how difficult to implement. e.g., I coul
On 7/1/13 6:29 PM, JS wrote:
Would would be nice is an experimental version of D where would could
easily extend the language to try out such concepts to see if they truly
are useful and how difficult to implement. e.g., I could attempt to add
said "feature", it could be merged with the experimen
On Monday, 1 July 2013 at 23:30:19 UTC, Andrei Alexandrescu wrote:
On 7/1/13 9:57 AM, JS wrote:
I think there is big confusion in what I'm "suggesting"(it's
not a
proposal because I don't expect anyone to take the time to
prove its
validity... and you can't know how useful it could be if you
d
On 7/1/2013 4:30 PM, Andrei Alexandrescu wrote:
Yes, and in fact it's already done. Consider:
if (expr)
{
int a;
...
}
else
{
int b;
...
}
In some C implementations, a and b have the same physical address. In some
others, they have distinct addresses. This appears to not be
On 7/1/13 9:57 AM, JS wrote:
I think there is big confusion in what I'm "suggesting"(it's not a
proposal because I don't expect anyone to take the time to prove its
validity... and you can't know how useful it could be if you don't have
any way to test it out).
It's two distinctly different conc
On 7/1/13 9:59 AM, Walter Bright wrote:
Sorry for the sarcasm, but I just don't get the notion that it's a
burden to use a different name for a variable that has a different type
and a different purpose. I'd go further and say it is a bad practice to
use the same name for such.
Reducing the num
On 07/01/2013 10:51 AM, deadalnix wrote:
> I declared in the late 90s that a phone
> with a tactile screen on its whole surface was a stupid idea and that it
> would never work.
I still think so. :D
Ali
On Monday, 1 July 2013 at 17:51:02 UTC, deadalnix wrote:
On Monday, 1 July 2013 at 16:57:53 UTC, JS wrote:
(the above example is at the heart of the matter... regardless
if it is probably a valid semantic in D or easily to
implement(since no one knows and most don't care because they
think it
On 7/1/2013 10:51 AM, deadalnix wrote:
But if you one very stupid one, I declared in the late 90s that a phone with a
tactile screen on its whole surface was a stupid idea and that it would never
work.
I you look hard enough, I guess we all said the most stupid thing at some point.
We got to adm
On 7/1/2013 10:07 AM, Timon Gehr wrote:
module b;
int x;
module a;
void main(){
int x;
{
import b;
x = 2;
I'd encourage you to submit an enhancement request that would produce the
message:
Error: import b.x hides local declaration of x
}
import std.st
On Monday, 1 July 2013 at 16:57:53 UTC, JS wrote:
(the above example is at the heart of the matter... regardless
if it is probably a valid semantic in D or easily to
implement(since no one knows and most don't care because they
think it won't benefit them(just like how bill gates thought
all e
On 7/1/2013 9:57 AM, JS wrote:
The problem is when such a "idea" is present you get people who are
automatically against it for various irrational fears and they won't take any
serious look at it to see if it has any merit... If you jump to the conclusion
that something is useless without any re
Don't feed the troll.
On Monday, 1 July 2013 at 16:46:57 UTC, Ary Borenszweig wrote:
Ah, that's also ok. But then you have to remember to use myVar
instead of var.
I have wanted to remove a variable from scope before. I think it
would be kinda cool if we could do something like __undefine(x),
and subsequent uses o
On 07/01/2013 06:15 PM, Walter Bright wrote:
On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
This is not what I am talking about and it seems quite dangerous to have
one variable name masquerade as multiple variables.
Why dangerous?
D already disallows:
int x;
{ float x;
}
as
On Monday, 1 July 2013 at 16:46:57 UTC, Ary Borenszweig wrote:
On 7/1/13 1:45 PM, John Colvin wrote:
T)(T var)
{
auto myVar = var.to!string;
//do something with myVar string
}
Ah, that's also ok. But then you have to remember to use myVar
instead of var.
Personally I like the explic
On 7/1/2013 9:46 AM, Ary Borenszweig wrote:
On 7/1/13 1:45 PM, John Colvin wrote:
T)(T var)
{
auto myVar = var.to!string;
//do something with myVar string
}
Ah, that's also ok. But then you have to remember to use myVar instead of var.
Heck, why bother with different variable names
On Monday, 1 July 2013 at 16:15:04 UTC, Walter Bright wrote:
On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
This is not what I am talking about and it seems quite
dangerous to have
one variable name masquerade as multiple variables.
Why dangerous?
D already disallows:
int x;
{ float
On Monday, 1 July 2013 at 16:33:56 UTC, Ary Borenszweig wrote:
I'll give you an example:
# var can be an Int or String
def foo(var)
var = var.to_s
# do something with var, which is now guaranteed to be a
string
end
I can call it like this:
foo(1)
foo("hello")
If I had to put types, I w
On 7/1/13 1:45 PM, John Colvin wrote:
T)(T var)
{
auto myVar = var.to!string;
//do something with myVar string
}
Ah, that's also ok. But then you have to remember to use myVar instead
of var.
On 7/1/13 1:15 PM, Walter Bright wrote:
On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
This is not what I am talking about and it seems quite dangerous to have
one variable name masquerade as multiple variables.
Why dangerous?
D already disallows:
int x;
{ float x;
}
as an er
On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
This is not what I am talking about and it seems quite dangerous to have
one variable name masquerade as multiple variables.
Why dangerous?
D already disallows:
int x;
{ float x;
}
as an error-prone construct, so why should it allow:
On 07/01/2013 03:44 PM, Ary Borenszweig wrote:
On 6/30/13 10:56 PM, Timon Gehr wrote:
On 07/01/2013 03:08 AM, Kenji Hara wrote:
2013/7/1 JS mailto:js.m...@gmail.com>>
I am simply talking about having the compiler enlarge the type if
needed. (this is mainly for built in types since the
On 6/30/13 10:56 PM, Timon Gehr wrote:
On 07/01/2013 03:08 AM, Kenji Hara wrote:
2013/7/1 JS mailto:js.m...@gmail.com>>
I am simply talking about having the compiler enlarge the type if
needed. (this is mainly for built in types since the type hierarchy
is explicitly known)
Just a
On 6/30/13 10:30 PM, JS wrote:
On Monday, 1 July 2013 at 01:08:49 UTC, Kenji Hara wrote:
2013/7/1 JS
I am simply talking about having the compiler enlarge the type if
needed.
(this is mainly for built in types since the type hierarchy is
explicitly
known)
Just a simple matter, it would *dr
On 6/30/13 7:39 PM, JS wrote:
On Saturday, 29 June 2013 at 19:18:13 UTC, Ary Borenszweig wrote:
On 6/27/13 9:34 PM, JS wrote:
Would it be possible for a language(specifically d) to have the ability
to automatically type a variable by looking at its use cases without
adding too much complexity?
On Monday, 1 July 2013 at 09:31:04 UTC, JS wrote:
On Monday, 1 July 2013 at 06:51:53 UTC, deadalnix wrote:
On Monday, 1 July 2013 at 06:38:20 UTC, JS wrote:
well duh, but it is quite a simple mathematical problem and
your counter-example is not one at all.
For a statically typed language all
On Monday, 1 July 2013 at 06:51:53 UTC, deadalnix wrote:
On Monday, 1 July 2013 at 06:38:20 UTC, JS wrote:
well duh, but it is quite a simple mathematical problem and
your counter-example is not one at all.
For a statically typed language all types must be known at
compile time... so you can'
On Monday, 1 July 2013 at 06:38:20 UTC, JS wrote:
well duh, but it is quite a simple mathematical problem and
your counter-example is not one at all.
For a statically typed language all types must be known at
compile time... so you can't come up with any valid
counter-example. Just because yo
On Monday, 1 July 2013 at 04:19:51 UTC, Timon Gehr wrote:
On 07/01/2013 05:44 AM, JS wrote:
On Monday, 1 July 2013 at 01:56:22 UTC, Timon Gehr wrote:
...
The described strategy can easily result in non-termination,
and which
template instantiations it performs can be non-obvious.
auto foo(T)
On 07/01/2013 05:44 AM, JS wrote:
On Monday, 1 July 2013 at 01:56:22 UTC, Timon Gehr wrote:
...
The described strategy can easily result in non-termination, and which
template instantiations it performs can be non-obvious.
auto foo(T)(T arg){
static if(is(T==int)) return 1.0;
else retur
On Monday, 1 July 2013 at 01:56:22 UTC, Timon Gehr wrote:
On 07/01/2013 03:08 AM, Kenji Hara wrote:
2013/7/1 JS mailto:js.m...@gmail.com>>
I am simply talking about having the compiler enlarge the
type if
needed. (this is mainly for built in types since the type
hierarchy
is explici
On 6/30/2013 6:08 PM, Kenji Hara wrote:
I can easily imagine that the compilation cost would not be worth the small
benefits.
There are arguably not even small benefits.
On Sun, 30 Jun 2013 21:56:21 -0400, Timon Gehr wrote:
The described strategy can easily result in non-termination, and which
template instantiations it performs can be non-obvious.
auto foo(T)(T arg){
static if(is(T==int)) return 1.0;
else return 1;
}
void main(){
auto x;
On 07/01/2013 03:08 AM, Kenji Hara wrote:
2013/7/1 JS mailto:js.m...@gmail.com>>
I am simply talking about having the compiler enlarge the type if
needed. (this is mainly for built in types since the type hierarchy
is explicitly known)
Just a simple matter, it would *drastically* i
On Monday, 1 July 2013 at 01:08:49 UTC, Kenji Hara wrote:
2013/7/1 JS
I am simply talking about having the compiler enlarge the type
if needed.
(this is mainly for built in types since the type hierarchy is
explicitly
known)
Just a simple matter, it would *drastically* increase
compilati
2013/7/1 JS
> I am simply talking about having the compiler enlarge the type if needed.
> (this is mainly for built in types since the type hierarchy is explicitly
> known)
>
Just a simple matter, it would *drastically* increase compilation time.
void foo()
{
auto elem;
auto arr = [elem
On Saturday, 29 June 2013 at 19:18:13 UTC, Ary Borenszweig wrote:
On 6/27/13 9:34 PM, JS wrote:
Would it be possible for a language(specifically d) to have
the ability
to automatically type a variable by looking at its use cases
without
adding too much complexity? It seems to me that most compi
On 6/29/2013 4:08 PM, Ary Borenszweig wrote:
That's a really good example you gave :-)
Thanks. I remember seeing it somewhere before, but can't recall just where.
On 6/29/13 7:30 PM, Walter Bright wrote:
On 6/29/2013 2:53 PM, Ary Borenszweig wrote:
On 6/29/13 6:01 PM, Walter Bright wrote:
On 6/29/2013 12:18 PM, Ary Borenszweig wrote:
What you are asking is essentially what Crystal does for all variables
(and types):
https://github.com/manastech/crystal
On Sat, 29 Jun 2013 17:01:54 -0400, Walter Bright
wrote:
On 6/29/2013 12:18 PM, Ary Borenszweig wrote:
What you are asking is essentially what Crystal does for all variables
(and types):
https://github.com/manastech/crystal/wiki/Introduction#type-inference
Your example would be written l
On 6/29/2013 2:53 PM, Ary Borenszweig wrote:
On 6/29/13 6:01 PM, Walter Bright wrote:
On 6/29/2013 12:18 PM, Ary Borenszweig wrote:
What you are asking is essentially what Crystal does for all variables
(and types):
https://github.com/manastech/crystal/wiki/Introduction#type-inference
Your ex
On 6/29/13 6:01 PM, Walter Bright wrote:
On 6/29/2013 12:18 PM, Ary Borenszweig wrote:
What you are asking is essentially what Crystal does for all variables
(and types):
https://github.com/manastech/crystal/wiki/Introduction#type-inference
Your example would be written like this:
x = 3
y = f
On 6/29/2013 12:18 PM, Ary Borenszweig wrote:
What you are asking is essentially what Crystal does for all variables (and
types):
https://github.com/manastech/crystal/wiki/Introduction#type-inference
Your example would be written like this:
x = 3
y = f()
x = 3.9
But since Crystal transforms
On 6/27/13 9:34 PM, JS wrote:
Would it be possible for a language(specifically d) to have the ability
to automatically type a variable by looking at its use cases without
adding too much complexity? It seems to me that most compilers already
can infer type mismatchs which would allow them to hand
On Fri, 28 Jun 2013 18:00:54 -0400, JS wrote:
On Friday, 28 June 2013 at 14:02:07 UTC, Steven Schveighoffer wrote:
On Fri, 28 Jun 2013 02:51:39 -0400, JS My argument
is that auto should be left the way it is. I don't want it to change.
And variant already does what you want with less con
On Saturday, 29 June 2013 at 02:05:35 UTC, Walter Bright wrote:
On 6/28/2013 6:48 PM, JS wrote:
What was the use case for auto that got in into the language?
In code where the type of the initializer would change, and if
the type of the variable was fixed, then there would be an
unintended i
On 6/28/2013 6:48 PM, JS wrote:
What was the use case for auto that got in into the language?
In code where the type of the initializer would change, and if the type of the
variable was fixed, then there would be an unintended implicit conversion. The
other use case was voldemort types. Such
On Saturday, 29 June 2013 at 01:49:01 UTC, JS wrote:
On Saturday, 29 June 2013 at 01:31:13 UTC, Walter Bright wrote:
On 6/28/2013 5:00 PM, JS wrote:
Is variant useful? If not then you have a point. I'm not
proposing anything that
variant can't already do except add compile time performance.
I
On Saturday, 29 June 2013 at 01:31:13 UTC, Walter Bright wrote:
On 6/28/2013 5:00 PM, JS wrote:
Is variant useful? If not then you have a point. I'm not
proposing anything that
variant can't already do except add compile time performance.
I do not think the
complexity is much more than what is
On 6/28/2013 4:42 PM, Timon Gehr wrote:
On 06/29/2013 12:29 AM, Walter Bright wrote:
I don't see a compelling use case for this proposal, or even any use
case. There'd have to be some serious advantage to it to justify its
complexity.
Eg:
auto a;
typeof(cache[x]) a; // (1)
if(x in c
On 6/28/2013 5:00 PM, JS wrote:
Is variant useful? If not then you have a point. I'm not proposing anything that
variant can't already do except add compile time performance. I do not think the
complexity is much more than what is already done.
D already checks for time mismatch. With such a var
On Friday, 28 June 2013 at 22:29:21 UTC, Walter Bright wrote:
On 6/27/2013 5:34 PM, JS wrote:
Would it be possible for a language(specifically d) to have
the ability to
automatically type a variable by looking at its use cases
without adding too
much complexity? It seems to me that most compile
On 06/29/2013 12:29 AM, Walter Bright wrote:
On 6/27/2013 5:34 PM, JS wrote:
Would it be possible for a language(specifically d) to have the
ability to
automatically type a variable by looking at its use cases without
adding too
much complexity? It seems to me that most compilers already can inf
On Friday, 28 June 2013 at 22:29:21 UTC, Walter Bright wrote:
On 6/27/2013 5:34 PM, JS wrote:
Would it be possible for a language(specifically d) to have
the ability to
automatically type a variable by looking at its use cases
without adding too
much complexity? It seems to me that most compile
On 6/27/2013 5:34 PM, JS wrote:
Would it be possible for a language(specifically d) to have the ability to
automatically type a variable by looking at its use cases without adding too
much complexity? It seems to me that most compilers already can infer type
mismatchs which would allow them to ha
On Friday, 28 June 2013 at 14:02:07 UTC, Steven Schveighoffer
wrote:
On Fri, 28 Jun 2013 02:51:39 -0400, JS My
argument is that auto should be left the way it is. I don't
want it to change. And variant already does what you want with
less confusing semantics, no reason to add another feature
Brian Rogoff:
No, OCaml doesn't quite do what the OP is asking for. In
particular, the part where x is assigned an int and
subsequently assigned a float can not be modeled directly.
I see, then this is not related to the flow typing I have linked
to, sorry.
Bye,
bearophile
On Friday, 28 June 2013 at 13:44:19 UTC, ponce wrote:
On Friday, 28 June 2013 at 00:34:54 UTC, JS wrote:
Would it be possible for a language(specifically d) to have
the ability to automatically type a variable by looking at its
use cases without adding too much complexity?
Well ocaml has it
On 06/28/2013 03:44 PM, ponce wrote:
On Friday, 28 June 2013 at 00:34:54 UTC, JS wrote:
Would it be possible for a language(specifically d) to have the
ability to automatically type a variable by looking at its use cases
without adding too much complexity?
Well ocaml has it (https://en.wikiped
On Fri, 28 Jun 2013 02:51:39 -0400, JS wrote:
On Friday, 28 June 2013 at 00:48:23 UTC, Steven Schveighoffer wrote:
On Thu, 27 Jun 2013 20:34:53 -0400, JS wrote:
Would it be possible for a language(specifically d) to have the
ability to automatically type a variable by looking at its use ca
ponce:
Well ocaml has it
(https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner) and well
it's not all that positive, at least in that language.
I think a H-M global type inferencer is not needed for what the
OP is asking for, that is limited _inside_ functions, so it's not
global. See the f
On Friday, 28 June 2013 at 07:04:12 UTC, Jonathan M Davis wrote:
On Friday, June 28, 2013 02:34:53 JS wrote:
Would it be possible for a language(specifically d) to have the
ability to automatically type a variable by looking at its use
cases without adding too much complexity? It seems to me tha
On Friday, 28 June 2013 at 00:34:54 UTC, JS wrote:
Would it be possible for a language(specifically d) to have the
ability to automatically type a variable by looking at its use
cases without adding too much complexity?
Well ocaml has it
(https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner)
On Friday, June 28, 2013 02:34:53 JS wrote:
> Would it be possible for a language(specifically d) to have the
> ability to automatically type a variable by looking at its use
> cases without adding too much complexity? It seems to me that
> most compilers already can infer type mismatchs which woul
On Friday, 28 June 2013 at 00:48:23 UTC, Steven Schveighoffer
wrote:
On Thu, 27 Jun 2013 20:34:53 -0400, JS
wrote:
Would it be possible for a language(specifically d) to have
the ability to automatically type a variable by looking at its
use cases without adding too much complexity? It seems
JS:
in this case x and y's type is inferred from future use. The
compiler essentially just lazily infers the variable type.
Obviously ambiguity will generate an error.
Do you mean the flow-sensitive typing of the Whiley language?
http://whiley.org/guide/typing/flow-typing/
It's surely neat.
On Thu, 27 Jun 2013 20:34:53 -0400, JS wrote:
Would it be possible for a language(specifically d) to have the ability
to automatically type a variable by looking at its use cases without
adding too much complexity? It seems to me that most compilers already
can infer type mismatchs which w
I believe it would be possible. D does something similar for auto
return values on functions already. Might be a bit of work in
the compiler though.
74 matches
Mail list logo
