On Thursday, 20 September 2018 at 05:04:49 UTC, Neia Neutuladh
wrote:
On Thursday, 20 September 2018 at 04:41:21 UTC, Joakim wrote:
Nice, what will it take to get this integrated with the
official dub website?
I need to:
* add JSON output to the auto-tester
* get the dub registry to scrape
On Thursday, 20 September 2018 at 04:41:21 UTC, Joakim wrote:
Nice, what will it take to get this integrated with the
official dub website?
I need to:
* add JSON output to the auto-tester
* get the dub registry to scrape the data (or, optionally, push
the data to the registry, but that opens
On Thursday, 20 September 2018 at 04:16:41 UTC, Neia Neutuladh
wrote:
On Thursday, 20 September 2018 at 02:51:52 UTC, Neia Neutuladh
wrote:
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh
wrote:
Not on dlang.org anywhere, but I built a crude version of
this. Results are available a
On Sunday, 20 May 2018 at 23:01:39 UTC, Charles Hixson wrote:
auto has its uses, but it's wildly overused, especially in
library code and documentation, and really, really, *really*
much so in documentation examples.
A lot of functions in `std.algorithm` are actually quite clear
abo
auto has its uses, but it's wildly overused, especially in library code
and documentation, and really, really, *really* much so in documentation
examples.
On 05/01/2018 06:09 AM, Craig Dillabaugh via Digitalmars-d wrote:
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'
On Sunday, 20 May 2018 at 14:35:21 UTC, I love Ice Cream wrote:
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
D is very hard to make an IDE for that would actually tell you
what type the return value is.
This might sound a little hard, but that's probably a
fundamental failure
ncept of returning a
> 'compiler determined type'. But the rules are always baked into
> the API. If it's not, it's a design failure and more thought
> should be put into it.
>
> The only place I wouldn't be so strict with auto returns is in
> private methods
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
D is very hard to make an IDE for that would actually tell you
what type the return value is.
This might sound a little hard, but that's probably a fundamental
failure of the D language and explains some of the poor tooling
around
, it's a design failure and more thought
should be put into it.
The only place I wouldn't be so strict with auto returns is in
private methods. However, I still might tell someone to think
about what they are trying to return there. It's not an
unimportant piece of the API.
ake an IDE for that would actually tell you
what type the return value is. `pragma(msg, typeof(foo))` is
probably your best bet, and that's kind of terrible.
Oh, there's also one other use of `auto` return types that I
haven't seen mentioned before: it functions as a DMD pragma to
inc
'auto' in the sense that C# and other languages use 'var' makes
perfect sense. There is nothing wrong with it and it takes out
redundant 'noise':
var i = "This is a string"; // don't need to know two times
that this is a string.
var j = So
On Friday, 18 May 2018 at 16:25:52 UTC, Neia Neutuladh wrote:
On Friday, 18 May 2018 at 10:09:20 UTC, Chris wrote:
In a way Java has slowly been moving in that direction anyway,
cf. this answer [2] that reminded me of D's `auto` return type.
[2]
https://stackoverflow.com/questions/1348199
On Friday, 18 May 2018 at 10:09:20 UTC, Chris wrote:
In a way Java has slowly been moving in that direction anyway,
cf. this answer [2] that reminded me of D's `auto` return type.
[2]
https://stackoverflow.com/questions/1348199/what-is-the-difference-between-the-hashmap-and-map-objects-in
would
go to such length only to insist on type inference.
In part this can be due to unreasonably difficult to spell
types like ptrdiff_t, so I try to design my code in a way that
it's easy to spell types.
I was working with Java 8 this week, and God did I miss `auto`.
And now Java will get
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'll freely admit I haven't put a ton of thought into this post
(never a good start), however I'm genuinely curious what
people's feeling are with regards to the auto keyword.
I prefer types spelled as it helps to und
On Wednesday, 16 May 2018 at 10:52:42 UTC, KingJoffrey wrote:
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
So I'm curious, what's the consensus on auto?
In the example below, what would I use, besides auto?
auto is required for Voldemort types, so you would change it to
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
So I'm curious, what's the consensus on auto?
In the example below, what would I use, besides auto?
module test;
void main ()
{
import std.stdio : writeln;
auto result = newKing(&qu
se the return type. In some
> cases, that means returning a specific type, whereas in
> others, it means using auto and being clear in the
> documentation about what kind of API the return type has. As
> long as the API is clear, then auto can be fantastic, but if
> the documentat
On Fri, May 11, 2018 at 06:56:13PM +, Chris M. via Digitalmars-d wrote:
> On Friday, 11 May 2018 at 18:44:25 UTC, H. S. Teoh wrote:
> > On Fri, May 11, 2018 at 04:57:05PM +, Mark via Digitalmars-d wrote:
> > > [...]
> >
> > This makes me wonder if it might be useful to have return-type
> >
On Friday, 11 May 2018 at 18:44:25 UTC, H. S. Teoh wrote:
On Fri, May 11, 2018 at 04:57:05PM +, Mark via
Digitalmars-d wrote:
[...]
This makes me wonder if it might be useful to have return-type
constraints. A kind of static out-contract? Something that's
part of the function declarati
> > returning a specific type, whereas in others, it means using auto
> > and being clear in the documentation about what kind of API the
> > return type has. As long as the API is clear, then auto can be
> > fantastic, but if the documentation is poorly written (or
> > no
On Wednesday, 9 May 2018 at 15:06:55 UTC, Jonathan M Davis wrote:
Ultimately, the key is that the user of the function needs to
be able to know how to use the return type. In some cases, that
means returning a specific type, whereas in others, it means
using auto and being clear in the
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
So I'm curious, what's the consensus on auto?
My rule, is when I can't be bothered typing it all out, or can't
be bothered working out what it is I'm actually meant to type,
then I use auto (or var).
i.e.
On Wednesday, May 09, 2018 14:31:00 Jesse Phillips via Digitalmars-d wrote:
> On Wednesday, 9 May 2018 at 13:22:56 UTC, bauss wrote:
> > Using "auto" you can also have multiple return types.
> >
> > auto foo(T)(T value)
> > {
> >
> > static i
On Wednesday, 9 May 2018 at 13:22:56 UTC, bauss wrote:
Using "auto" you can also have multiple return types.
auto foo(T)(T value)
{
static if (is(T == int)) return "int: " ~ to!string(value);
else return value;
}
You cannot give that function a specific return type
other benefits.
[...]
Using "auto" you can also have multiple return types.
auto foo(T)(T value)
{
static if (is(T == int)) return "int: " ~ to!string(value);
else return value;
}
You cannot give that function a specific return type as it's
either T or it's string. It's not a single type.
On Monday, April 30, 2018 21:11:07 Gerald via Digitalmars-d wrote:
> I'll freely admit I haven't put a ton of thought into this post
> (never a good start), however I'm genuinely curious what people's
> feeling are with regards to the auto keyword.
>
> Spea
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'll freely admit I haven't put a ton of thought into this post
(never a good start), however I'm genuinely curious what
people's feeling are with regards to the auto keyword.
Speaking for myself, I dislike the auto k
does, however, assume that the
developer can also do type inference (when/if you need to know
the type). When it's not clear what the type is by looking at
the right-hand side perhaps the codebase has bigger problems.
functions that return auto are a bit odd IMHO, that is a
feature unique
On 05/04/2018 12:54 PM, H. S. Teoh wrote:
This is a good point. However, I'm failing to see it as a big problem,
because for it to be a problem in the first place, you have to have
*deliberately* passed an object of said type into a function that
expects that particular concept.
First of all,
On Fri, May 04, 2018 at 12:12:09AM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
[...]
> The problem with structural typing is that it's unable to distinguish
> between intended matches and accidental, unintended matches. This is
> because it doesn't REQUIRE types/functions/etc to cle
On 05/04/2018 03:56 AM, Laeeth Isharc wrote:
On Friday, 4 May 2018 at 04:12:09 UTC, Nick Sabalausky (Abscissa) wrote:
On 05/02/2018 10:05 AM, H. S. Teoh wrote:
[...]
I don't doubt that. Similar to global namespace, if the structural
typing is only used heavily by one or two components of a p
On Friday, 4 May 2018 at 04:12:09 UTC, Nick Sabalausky (Abscissa)
wrote:
On 05/02/2018 10:05 AM, H. S. Teoh wrote:
[...]
I don't doubt that. Similar to global namespace, if the
structural typing is only used heavily by one or two components
of a project (ie, libs, etc), then it's not too dif
On 05/02/2018 10:05 AM, H. S. Teoh wrote:
I've been using structural typing / design by introspection to good
success in my latest project, actually.
I don't doubt that. Similar to global namespace, if the structural
typing is only used heavily by one or two components of a project (ie,
libs
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
So I'm curious, what's the consensus on auto?
Speaking for myself:
1) I find auto to be useful when instantiating objects locally;
eliminates redundancy, noise, and line size.
2) I avoid auto functions and despise t
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'll freely admit I haven't put a ton of thought into this post
(never a good start), however I'm genuinely curious what
people's feeling are with regards to the auto keyword.
So I'm curious, what's the c
On Wednesday, 2 May 2018 at 14:05:49 UTC, H. S. Teoh wrote:
How else would you do DoI, though? With Concepts? The
advantage of using structural typing over concepts for DoI is
that you would need an exponential number of concepts to catch
up with a linear number of optional fields in a struct
On Wednesday, 2 May 2018 at 14:05:49 UTC, H. S. Teoh wrote:
How else would you do DoI, though? With Concepts? The
advantage of using structural typing over concepts for DoI is
that you would need an exponential number of concepts to catch
up with a linear number of optional fields in a struct
On Wed, May 02, 2018 at 12:11:57AM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 04/30/2018 05:35 PM, H. S. Teoh wrote:
> >
> > Also, design by introspection. Dependence on explicit types is so
> > last century. Design by introspection FTW! Decoupling your code
> > from expli
On Wednesday, 2 May 2018 at 00:01:42 UTC, Nick Sabalausky wrote:
Now, all that said, using auto for a function signature's
return type shouldn't usually be done, except in very careful,
specific "voldemort type" kinds of situations (and even then, I
dont see a real big p
On 04/30/2018 05:35 PM, H. S. Teoh wrote:
Also, design by introspection. Dependence on explicit types is so last
century. Design by introspection FTW! Decoupling your code from
explicit types makes it more encapsulated, and gives you incentive to
write more defensively, resulting in better, m
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
So I'm curious, what's the consensus on auto?
For local variables, it's not an unalloyed good, but it is good.
When I use Java, everything is explicit, and sometimes that's
nice. In D, I think I overuse `auto`
I'm a die-hard static typing fan, hate dynamic languages, heck I
dont even like structural typing (ex, as used by D ranges). And
that's exactly why I *love* auto. It lets you have static typing
without turning programming into a 2000's-era C++/Java-style
royal anti-DRY PITA.
I'm a die-hard static typing fan, hate dynamic languages, heck I
dont even like structural typing (ex, as used by D ranges). And
that's exactly why I *love* auto. It lets you have static typing
without turning programming into a 2000's-era C++/Java-style
royal anti-DRY PITA.
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'll freely admit I haven't put a ton of thought into this post
(never a good start), however I'm genuinely curious what
people's feeling are with regards to the auto keyword.
Speaking for myself, I dislike the auto k
to statically type in for loops:
foreach (i; items)
writefln("%s", i);
And, yeah, chainig would indeed be a PIA:
auto items = myRange.filter!(a => a.length);
Most of the time you don't really care about the exact type, only
at the end of the block (e.g. it should be `s
On Mon, Apr 30, 2018 at 09:31:48PM +, Giles Bathgate via Digitalmars-d
wrote:
[...]
> functions that return auto are a bit odd IMHO, that is a feature
> unique to D. But I don't have a problem with type inference in
> general, all language have it including C#, C++, TypeScript
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'll freely admit I haven't put a ton of thought into this post
(never a good start), however I'm genuinely curious what
people's feeling are with regards to the auto keyword.
Speaking for myself, I dislike the auto k
On Mon, Apr 30, 2018 at 09:11:07PM +, Gerald via Digitalmars-d wrote:
[...]
> So I'm curious, what's the consensus on auto?
Don't know what others think, but personally, it's one of the best
things about D: all the safety of static typing, yet with the
convenience of a
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
Speaking for myself, I dislike the auto keyword. Some of this
is because I have a preference for static languages and I find
auto adds ambiguity with little benefit. Additionally, I find
it annoying that the phobos documentation relies
I'll freely admit I haven't put a ton of thought into this post
(never a good start), however I'm genuinely curious what people's
feeling are with regards to the auto keyword.
Speaking for myself, I dislike the auto keyword. Some of this is
because I have a preference for
On Thursday, 22 March 2018 at 05:00:07 UTC, John Belmonte wrote:
On Thursday, 22 March 2018 at 04:25:00 UTC, Seb wrote:
- Every time a PR is merged at dmd, druntime or phobos ALL
auto-tester results get invalidated
If a change on the destination branch causes a PR to require an
automatic
On Thursday, 22 March 2018 at 04:25:00 UTC, Seb wrote:
- Every time a PR is merged at dmd, druntime or phobos ALL
auto-tester results get invalidated
If a change on the destination branch causes a PR to require an
automatic merge, certainly build and tests should be rerun. But
if the two
On Thursday, 22 March 2018 at 04:17:52 UTC, Mike Franklin wrote:
On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:
I'm still rather puzzled. My pull request remains with 8
tests pending after several hours. I can't find any
confirmation on the pulls display
ht
a priority affecting which PRs get tested first.
Those that are labeled with "AutoMerge" are given a higher
priority.
I'm still rather puzzled. My pull request remains with 8 tests
pending after several hours. I can't find any confirmation on
the pulls d
On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:
I'm still rather puzzled. My pull request remains with 8 tests
pending after several hours. I can't find any confirmation on
the pulls display
https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that
it inte
On Thursday, 22 March 2018 at 04:17:52 UTC, Mike Franklin wrote:
Let's see what happens after the auto-tester starts testing it
again.
Note that it could be a while, as there are PRs that will be
getting merged in the next 24 hours that will restart the test
queue.
Mike
labeled with "AutoMerge" are given a higher
priority.
I'm still rather puzzled. My pull request remains with 8 tests
pending after several hours. I can't find any confirmation on
the pulls display
https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that it
inte
On Thursday, 22 March 2018 at 01:46:08 UTC, John Belmonte wrote:
I'm trying to understand why my pull request was queued in D2
Auto-Test for only 2 of 8 tests, with the remaining left in
pending state.
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1&repoid=1&am
I'm trying to understand why my pull request was queued in D2
Auto-Test for only 2 of 8 tests, with the remaining left in
pending state.
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1&repoid=1&pullid=8051
Since there are pending tests, I'd expect i
On Monday, 5 March 2018 at 13:03:50 UTC, Steven Schveighoffer
wrote:
On 3/2/18 8:49 PM, Jonathan Marler wrote:
On Saturday, 3 March 2018 at 00:20:14 UTC, H. S. Teoh wrote:
On Fri, Mar 02, 2018 at 11:51:08PM +, Jonathan Marler via
Digitalmars-d wrote:
[...]
Not true:
template counter
On 3/2/18 8:49 PM, Jonathan Marler wrote:
On Saturday, 3 March 2018 at 00:20:14 UTC, H. S. Teoh wrote:
On Fri, Mar 02, 2018 at 11:51:08PM +, Jonathan Marler via
Digitalmars-d wrote:
[...]
Not true:
template counterexample(alias T) {}
int x;
string s;
alias U = counterexa
On Saturday, 3 March 2018 at 00:20:14 UTC, H. S. Teoh wrote:
On Fri, Mar 02, 2018 at 11:51:08PM +, Jonathan Marler via
Digitalmars-d wrote:
[...]
Not true:
template counterexample(alias T) {}
int x;
string s;
alias U = counterexample!x; // OK
a
On 03.03.2018 01:20, H. S. Teoh wrote:
On Fri, Mar 02, 2018 at 11:51:08PM +, Jonathan Marler via Digitalmars-d
wrote:
I believe I found small hole in template parameter semantics.
[...] you can't create a template that accepts a value of any type.
Not true:
template counterexample
On Fri, Mar 02, 2018 at 11:51:08PM +, Jonathan Marler via Digitalmars-d
wrote:
> I believe I found small hole in template parameter semantics.
> [...] you can't create a template that accepts a value of any type.
Not true:
template counterexample(alias T) {}
int x;
s
I believe I found small hole in template parameter semantics.
I've summarized it here
(https://github.com/marler8997/dlangfeatures#template-auto-value-parameter). Wanted to get feedback before I look into creating a PR for it.
--
COPY/PASTED from
nts? For instance, for the function:
auto map(Range)(Range r) if (isInputRange!(Unqual!Range));
we'd add the following to its constraints:
isInputRange!(ReturnType!(map!R))
However, this does not compile at the moment. I'm not sure why.
I'm not sure why either, but signatu
that the return types are compatible is an iffy proposition at
best.
Keeping the return types opaque helps to discourage this sort of
misplaced assumption in user code.
> Like I might read the docs and, quite reasonably, write:
>
> auto capture = needFirst ? matchFirst(str, regex) :
On Wednesday, 27 December 2017 at 16:36:59 UTC, H. S. Teoh wrote:
The best we can do currently, which unfortunately won't show up
in the docs, is to use a static assert to force compilation
failure when the return type doesn't match expectations, e.g.:
[...]
static assert(isInp
On Tue, Dec 26, 2017 at 11:28:56AM +, Mark via Digitalmars-d wrote:
> On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote:
> > While I agree that all template parameters ought to be documented
> > and all auto return types thoroughly described, I disagree with
> &g
On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote:
On Mon, Dec 25, 2017 at 04:26:52PM +, Piotr Klos via
Digitalmars-d wrote:
On Monday, 25 December 2017 at 03:23:33 UTC, Neia Neutuladh
wrote:
> If you have a function with a return type listed as `auto`,
> please thor
On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote:
While I agree that all template parameters ought to be
documented and all auto return types thoroughly described, I
disagree with explicit naming of auto return types. The whole
point of auto return types is to return an *opaque
way besides using a unique type
for each (hello, std.typecons.Typedef). Like I might read the
docs and, quite reasonably, write:
auto capture = needFirst ? matchFirst(str, regex) :
matchAll(str, regex).skip(3).front;
auto process = asShell ? spawnShell("echo hi") :
spawnProcess([&qu
On Mon, Dec 25, 2017 at 04:26:52PM +, Piotr Klos via Digitalmars-d wrote:
> On Monday, 25 December 2017 at 03:23:33 UTC, Neia Neutuladh wrote:
> > If you have a function with a return type listed as `auto`, please
> > thoroughly describe what interface the return value provid
On Monday, 25 December 2017 at 03:23:33 UTC, Neia Neutuladh wrote:
If you have a function with a return type listed as `auto`,
please thoroughly describe what interface the return value
provides.
I would just like to say that I strongly agree. Lack of
documentation of template parameters
I would like to fix this using signatures[0].
Signatures have a number of benefits here, including removing of
TypeInfo (which prevents code-bloat).
There is a few other examples based upon allocators here[1].
But this isn't a short term goal even if it does get approved ;)
[0] https://github
If you have a function with a return type listed as `auto`,
please thoroughly describe what interface the return value
provides.
"Returns a forward range of Elem", where Elem is a template
parameter, is fine, for instance.
But look at std.regex.RegexMatch.front:
"Fu
On Thursday, 19 October 2017 at 01:05:28 UTC, Jonathan M Davis
wrote:
On Thursday, October 19, 2017 00:00:54 Dave Jones via
That's likely the main reason in this case, since losing the
ref-ness could definitely cause issues with some constructors,
but auto ref is frequently used simp
I noticed...
> >>
> >> T* emplace(T, Args...)(T* chunk, auto ref Args args)
> >>
> >> what does the "auto ref" do in this situiation? Cant seem to
> >> find any explanation in the docs.
> >
> > It means that any argument (that
On Wednesday, 18 October 2017 at 22:16:32 UTC, Moritz Maxeiner
wrote:
On Wednesday, 18 October 2017 at 21:38:41 UTC, Dave Jones wrote:
Poking around in the source code for emplace and I noticed...
T* emplace(T, Args...)(T* chunk, auto ref Args args)
what does the "auto ref"
On Wednesday, 18 October 2017 at 21:38:41 UTC, Dave Jones wrote:
Poking around in the source code for emplace and I noticed...
T* emplace(T, Args...)(T* chunk, auto ref Args args)
what does the "auto ref" do in this situiation? Cant seem to
find any explanation in the docs.
It
On Wednesday, 18 October 2017 at 21:38:41 UTC, Dave Jones wrote:
Poking around in the source code for emplace and I noticed...
T* emplace(T, Args...)(T* chunk, auto ref Args args)
what does the "auto ref" do in this situiation? Cant seem to
find any explanation in the docs.
sorr
Poking around in the source code for emplace and I noticed...
T* emplace(T, Args...)(T* chunk, auto ref Args args)
what does the "auto ref" do in this situiation? Cant seem to find
any explanation in the docs.
My Dynamic array complete show is good but when assign it's one
index to a variable, it's saves ASCII of that index.
writeln(myarray); // output 24
var = myarray[0]; // it assign 50 to var
Why changed to ASCII and how to get rid of please...
000, Meta via
> Digitalmars-d wrote:
> > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:
> > > Create an auto pointer, handy in some cases and fits in
> > > the language as a natural generalization.
> >
> > It's been suggested before (as well
On Thursday, 6 July 2017 at 20:24:24 UTC, FoxyBrown wrote:
On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote:
On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via
Digitalmars-d wrote:
Create an auto pointer, handy in some cases and fits in the
language as a natural generalization
On Friday, 7 July 2017 at 00:58:57 UTC, jmh530 wrote:
On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote:
(https://github.com/dlang/dmd/pull/3615)
Of course this could also get confusing pretty fast. I wish we
at least had the `int[$]` syntax but it's not a huge loss.
Thanks for posting th
On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote:
(https://github.com/dlang/dmd/pull/3615)
Of course this could also get confusing pretty fast. I wish we
at least had the `int[$]` syntax but it's not a huge loss.
Thanks for posting the link. Made for interesting reading.
This was another
On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote:
On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via
Digitalmars-d wrote: [...]
Let's say you have.
auto a = foo();
You have no idea what auto actually is in that case, but
auto* a = foo();
You know auto is a pointer of whateve
On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote:
On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via
Digitalmars-d wrote: [...]
Let's say you have.
auto a = foo();
You have no idea what auto actually is in that case, but
auto* a = foo();
You know auto is a pointer of whateve
On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via Digitalmars-d wrote:
[...]
> Let's say you have.
>
> auto a = foo();
>
> You have no idea what auto actually is in that case, but
>
> auto* a = foo();
>
> You know auto is a pointer of whatever foo returns.
sday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:
> > > Create an auto pointer, handy in some cases and fits in
> > > the language as a natural generalization.
> >
> > It's been suggested before (as well as more powerful
> > generalization for slices and
On Thu, Jul 06, 2017 at 10:31:10PM +, Meta via Digitalmars-d wrote:
> On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote:
> > On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote:
> > > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:
>
On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote:
On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via
Digitalmars-d wrote:
On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:
> Create an auto pointer, handy in some cases and fits in the
> language as a natural generali
On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote:
> On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:
> > Create an auto pointer, handy in some cases and fits in the language
> > as a natural generalization.
>
> It's been suggested before
On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:
Create an auto pointer, handy in some cases and fits in the
language as a natural generalization.
It's been suggested before (as well as more powerful
generalization for slices and associative arrays), but Andrei
vetoed it
On 07/06/2017 01:24 PM, FoxyBrown wrote:
> On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote:
>> On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d
>> wrote:
>>> Create an auto pointer, handy in some cases and fits in the language
>>
On Thu, Jul 06, 2017 at 08:24:24PM +, FoxyBrown via Digitalmars-d wrote:
[...]
> auto x = ...
>
> auto* x = ...
>
> auto* is the pointerized version of auto.
>
>
> e.g.,
>
> int x = ...
>
> int* x = ...
>
> typeof(x) y = ...
> typeof(
On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote:
On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via
Digitalmars-d wrote:
Create an auto pointer, handy in some cases and fits in the
language as a natural generalization.
What's an auto pointer?
T
is it not obvious?
a
On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d wrote:
> Create an auto pointer, handy in some cases and fits in the language
> as a natural generalization.
What's an auto pointer?
T
--
Truth, Sir, is a cow which will give [skeptics] no more milk, and so the
1 - 100 of 1018 matches
Mail list logo
