I don't think this is a language issue, as said warnings and fix-its
are really useful.
In the other handm when watching other programmers in other languages
without IDE triggering a compile trough the terminal I see that it
allows them to put all their ideas into code first, and then deal with
war
I feel like warnings showing up as you type are an IDE's responsibility.
Annotations to delay warnings seem like noise. Once you get used to
programming you don't need the annotations.
If warnings are bothersome, then turn it off in the Xcode settings!
On Thu, Feb 2, 2017 at 1:34 PM Pierre M
+1 to the proposal
+1 to teach how to remove live issues to beginners, so they have a chance to
train at detecting errors without the compiler
Pierre
> Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution
> a écrit :
>
> +1
>
> On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-e
+1
On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:
> One of the biggest issues that I saw while teaching Swift to newbies (most
> had not programmed before) is confusion based on the early warnings/errors
> that swift/xcode gives you as they typ
> One of the biggest issues that I saw while teaching Swift to newbies (most
> had not programmed before) is confusion based on the early warnings/errors
> that swift/xcode gives you as they type. What would happen is that they
> would type a variable, and it would say… “You haven’t used this v
> On 26 Jan 2017, at 20:45, charles--- via swift-evolution
> wrote:
>
> +1
>
> Strongly in favour of this one. One of those things that seems obvious in
> retrospect
>
> It would also make the language more enjoyable to code in.
For you maybe. I like having the issues pop up and then disapp
+1
Strongly in favour of this one. One of those things that seems obvious in
retrospect
It would also make the language more enjoyable to code in. When Xcode nags me
about my function not providing a return value when I've only just started
writing it, I get the irrational urge to tell Xcode t
There's nothing wrong with fix-its and error messages, and indeed they can
be quite helpful-the issue is that sometimes they show up when they really
shouldn't, like in the middle of typing a line. Novices will then often
stop and see what it's trying to say (wouldn't you trust a tool if it tells
y
OTOH, looking at fixit and error messages can also aid in understanding Swift
better.
Seeing what happens when it happens is something I find quite useful.
Not that I have anything against the proposal, but I do wonder if that is the
best usage of available resources.
A BIG OT warning:
If peo
This sounds wonderful. It’s extremely common, in my experience with junior
developers, for them to blindly accept Xcode’s suggestions—and why wouldn’t
they? Delaying the display would certainly be a benefit for everyone, but
especially people who are just learning Swift.
Jeff Kelley
slauncha...@
+1, provided these differences are ignored if the user manually builds a
project. Hopefully this takes some of the load off of SourceKitService.
On Wed, Jan 25, 2017 at 16:07 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:
> Yes. It would stick once it appears (until it is f
Yes. It would stick once it appears (until it is fixed, of course)
> On Jan 25, 2017, at 4:02 PM, Xiaodi Wu wrote:
>
> I didn't read the proposal to mean vanish; rather, just lazily displayed
> until some condition, but then permanently there once it shows up. It really
> is annoying to be co
I didn't read the proposal to mean vanish; rather, just lazily displayed
until some condition, but then permanently there once it shows up. It
really is annoying to be constantly reminded you haven't used a variable
when you've literally just declared it. Once you've left the scope once,
it's fair
> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution
> wrote:
>
> One of the biggest issues that I saw while teaching Swift to newbies (most
> had not programmed before) is confusion based on the early warnings/errors
> that swift/xcode gives you as they type. What would happen is t
I'd quibble with you on the detailed design, but personally I think the
general idea is quite wonderful.
Quibble:
I don't particularly think different-scope and different-function are in
practice usefully distinct. And I think that for maximum elegance we could
parallel the supported access levels
15 matches
Mail list logo
