I wrote:

> I wrote:
> 
> > John Beckett wrote:
> > 
> > > On Thursday, February 10, 2022 at 12:27:18 AM UTC+11 Bram Moolenaar wrote:
> > > 
> > > > This comes from converting a legacy script to Vim9. So the question is
> > > > whether it is good to force removing the "s:" prefix or is it more
> > > > convenient to let it there?
> > > 
> > > If s: is never needed in vim9script, it should be an error to include it. 
> > > As someone learning to use the new system, I want firm guidance—should I 
> > > include s: or not? If I see it in someone's script, I'm going to wonder 
> > > if 
> > > it should be in mine (perhaps there is a performance advantage or 
> > > something 
> > > else I don't know about). It wastes everyone's time if arcane syntax is 
> > > sometimes used.
> > > 
> > > There will never be another opportunity to decide how vim9script should 
> > > work.
> > 
> > It's definitely cleaner to just disallow using "s:" in any Vim9 script.
> > It fits in with not allowing defining script level items (functions and
> > variables) in a function.
> > 
> > It is required of the user to understand that functions without "s:" are
> > script-local, but was already the case anyway, since it could be left
> > out.
> > 
> > Let me look into it, see what would fail.
> 
> One situation where we would still need to use "s:" is when a :def
> function is used in a legacy script.  There it is possible to create a
> new script variable, and also :unlet it.
> 
> This is the opposite of using a legacy function in a Vim9 script, where
> it is required to use the "s:" prefix to access script-local variables.
> It is even possible to define new script-local variables.  But :unlet
> can't be used, which is inconsistent.  We probably need to disallow
> creating new script variables, they should be declared at the script
> level.

This is what we would have then:

 - Vim9 script at script level: "s:" NOT allowed.
 - Vim9 script in :def function: "s:" NOT allowed.
 - Vim9 script in legacy function: "s:" required for script items.
 - legacy script at script level: "s:" required for script items.
 - legacy script in :def function: "s:" required for script items that are not
   defined yet, "s:" optional for existing script items.
 - legacy script in legacy function: "s:" required for script items

Is this logical?

An alternative is to only disallow using "s:" in Vim9 script at the
script level, but still allow it in all functions.  I believe that would
be the simplest rule.

So we have these choices:
- Leave as it is now, "s:" is optional everywhere
- Disallow "s:" in Vim9 script, only at the script level
- Disallow "s:" where it is not needed, as explained above


-- 
In many of the more relaxed civilizations on the Outer Eastern Rim of the
Galaxy, "The Hitchhiker's Guide to the Galaxy" has already supplanted the
great "Encyclopedia Galactica" as the standard repository of all knowledge
and wisdom, for though it has many omissions and contains much that is
apocryphal, or at least wildly inaccurate, it scores over the older, more
pedestrian work in two important respects.
First, it is slightly cheaper; and second, it has the words "DON'T PANIC"
inscribed in large friendly letters on its cover.
                -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///                                                                      \\\
\\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/20220211110859.ACDD21C0BBC%40moolenaar.net.

Raspunde prin e-mail lui